When a Claude Agent SDK is given unrestricted access, a single compromised prompt can extract or alter production data, leading to compliance penalties, lost customer trust, and costly remediation.
That risk stems from the classic segregation of duties problem: the same credential that can read sensitive tables is also able to write, delete, or export that data. In many organizations the SDK runs under a service account that has broad privileges because developers prioritize speed over fine‑grained control. The result is a single point of failure that blends the roles of data consumer, data modifier, and audit reporter.
Why segregation of duties matters for Claude Agent SDK
Segregation of duties is a control principle that requires critical functions to be divided among separate identities or processes. For the Claude Agent SDK, the principle translates into three practical questions:
- Who is allowed to query production data?
- Who may issue write or delete commands?
- Who can approve a change that could affect downstream systems?
If the same SDK instance can answer all three, an attacker who gains control of the prompt can bypass internal checks and directly impact the data store. Even without a breach, accidental misuse, such as a developer accidentally running a destructive command in a test prompt, can cause outages.
Typical setups fall short of true segregation
Most teams rely on identity providers and IAM policies to limit what a service account can do. Tokens are scoped, roles are assigned, and network firewalls restrict where the SDK can connect. Those measures are essential, but they stop at authentication. The SDK still talks directly to the database or other target, meaning:
- No real‑time audit of each query or mutation.
- No inline masking of personally identifiable information returned to the model.
- No approval workflow that forces a human to review high‑risk actions before they are executed.
- Credentials are stored in the runtime environment, so a compromised agent can exfiltrate them.
Because the enforcement point is missing, the segregation of duties promise is never fully realized.
Placing the enforcement point in the data path
To close the gap, the access control layer must sit between the Claude Agent SDK and the target resource. That is exactly where an identity‑aware gateway belongs. The gateway becomes the sole conduit for every request, allowing it to apply policy at the protocol level.
When the SDK initiates a connection, it reaches the gateway instead of the database directly. The gateway validates the user’s OIDC token, extracts group membership, and then decides whether the request complies with the segregation of duties policy. Because the gateway is the only place where traffic is inspected, it can enforce the following outcomes:
- Session recording: each interaction is captured for replay and audit, providing undeniable evidence of who did what.
- Inline data masking: sensitive fields such as credit‑card numbers are hidden before they ever reach the model, protecting PII while still allowing the model to reason over the data.
- Just‑in‑time access: the gateway grants read‑only permissions for a limited window, then automatically revokes them.
- Approval workflows: any write, delete, or schema‑change request is routed to an authorized reviewer who must approve before the gateway forwards it.
- Command blocking: dangerous commands (DROP DATABASE, ALTER USER, etc.) are identified and rejected without ever touching the target.
All of these enforcement outcomes exist only because the gateway sits in the data path. If the SDK were to bypass the gateway, none of the above protections would apply.
How to wire the Claude Agent SDK through the gateway
The integration is conceptually simple. Define a connection in the gateway configuration that points to the actual database or service the SDK needs. The gateway holds the credential; the SDK never sees it. Update the SDK’s endpoint to the gateway’s address and let the SDK use its normal client libraries (psql, MySQL client, etc.). Because authentication is handled by OIDC, no code changes are required in the SDK itself.
Once the traffic flows through the gateway, you can create policies that map to your segregation of duties model. For example, assign the "data‑reader" group read‑only rights and the "data‑writer" group rights that require an approval step for any INSERT, UPDATE, or DELETE. The gateway enforces those rules on every request, guaranteeing that the SDK cannot exceed its intended role.
Practical steps to achieve segregation of duties
- Identify the distinct roles your organization needs (e.g., analyst, developer, auditor).
- Create corresponding OIDC groups in your identity provider.
- Define gateway policies that bind each group to a specific set of commands and data‑masking rules.
- Configure the Claude Agent SDK to connect through the gateway’s address.
- Test the workflow: a read‑only user should see masked data, while a write request should trigger an approval prompt.
- Monitor the recorded sessions for unexpected activity and refine policies as needed.
Following this pattern ensures that the Claude Agent SDK respects segregation of duties, while still giving developers the flexibility to build powerful AI‑driven workflows.
Getting started with the gateway
For a quick deployment, see the getting started guide. The documentation walks you through launching the gateway with Docker Compose, registering a connection, and mapping OIDC groups to policies. For deeper insight into the feature set, explore the learn portal, which covers session recording, inline masking, and approval workflows in detail.
By placing the enforcement point in the data path, you turn a single, potentially over‑privileged Claude Agent SDK into a set of disciplined, auditable actors that honor segregation of duties.
Contribute or view the source on GitHub
