Access Reviews for the Claude Agent SDK

When every call the Claude Agent SDK makes to internal services is backed by a documented, regularly refreshed access review, teams know exactly who can invoke which model, what data may be returned, and can audit each request without disrupting the development workflow.

In many organizations the SDK is given a static API token that grants unrestricted access to all downstream endpoints. The token is stored in a configuration file or environment variable and rarely, if ever, examined after the initial deployment. Engineers treat the credential as a convenience, not a security control. The result is a long‑lived secret that can be used by any process that inherits the environment, and it often exceeds the principle of least privilege.

Without a systematic review process the organization loses visibility into who is allowed to run which prompt, which datasets are exposed, and whether the permissions still match business needs. Over‑privileged access increases the blast radius of a compromised service account, makes it harder to satisfy audit requirements, and creates friction when a legitimate user needs a tighter scope but cannot prove the need without a formal review.

Why access reviews matter for the Claude Agent SDK

Access reviews are a periodic, evidence‑based check that each identity’s granted scopes still align with its job function. For the Claude Agent SDK this means confirming that a given service account is authorized to request specific model capabilities, that it can retrieve only the data categories required for its workload, and that any elevated permissions have a documented business justification.

An effective review process includes three parts:

• Setup: identity providers issue short‑lived OIDC or SAML tokens to service accounts. The token carries group membership and role attributes that describe the intended scope.
• The data path: a gateway sits between the SDK and the target service, inspecting each request and response.
• Enforcement outcomes: the gateway records the session, masks any sensitive fields in the response, and can block or route a request for additional approval before it reaches the model.

Only when all three pieces are in place does an organization achieve a trustworthy access‑review loop.

Placing the gateway in the data path

Because the Claude Agent SDK communicates over HTTP, the gateway can proxy the SDK’s outbound calls. The gateway terminates the SDK’s TLS session, validates the caller’s identity token, and then re‑establishes a connection to the model endpoint using its own credential. This design guarantees that the SDK never sees the model’s secret, and that every request passes through a single, policy‑enforced choke point.

When a request arrives, the gateway checks the caller’s attributes against the current access‑review record. If the request matches an approved scope, the gateway forwards it. If the request exceeds the approved scope, the gateway can:

• Record the attempt for later audit.
• Mask any response fields that contain protected data.
• Pause the request and trigger a just‑in‑time approval workflow.

All of these enforcement outcomes are performed by the gateway itself, not by the SDK or the downstream model service. Removing the gateway would eliminate the audit trail, the masking, and the ability to intervene on over‑privileged calls.

How hoop.dev provides the required gateway

hoop.dev is an open‑source Layer 7 gateway that implements the data‑path controls described above. It integrates with any OIDC or SAML identity provider, reads group and role claims, and applies fine‑grained policies to each HTTP request. hoop.dev records each session, offers replay capability, and can mask sensitive fields in real time. Because the gateway runs inside the customer’s network, it never stores the model’s credentials in the SDK process.

To get started, follow the getting‑started guide and configure a connection that points to the Claude endpoint. The documentation explains how to map identity attributes to allowed model capabilities and how to enable inline masking for data‑sensitive responses. For deeper policy examples, see the learn section.

Benefits of a continuous access‑review loop

With hoop.dev in place, organizations gain:

• Visibility: every SDK request is logged with the caller’s identity and the policy decision.
• Control: requests that fall outside the approved scope are blocked or sent for manual approval.
• Data protection: sensitive response fields are masked before they reach the SDK.
• Compliance readiness: auditors can trace who accessed which model and verify that access reviews were performed on schedule.

These outcomes exist only because hoop.dev sits in the data path and enforces the policies derived from the access‑review process.

FAQ

Do I need to change my existing Claude SDK code?
No. The SDK continues to send HTTP requests as before; hoop.dev simply proxies those calls.

Can I use existing identity providers?
Yes. hoop.dev works with any OIDC or SAML provider, so you can keep your current IdP.

What happens to logs after a session ends?
hoop.dev records each session and provides logs that can be used for audit purposes.

Explore the source code and contribute on GitHub.