Putting access controls around Claude: production access for AI coding agents (on GCP)

Many teams assume that giving an AI coding agent like Claude unrestricted network reach is safe as long as the model is trained on internal code, but that bypasses production access controls. The reality is that a single compromised prompt can cause the agent to issue privileged commands, read secrets, or write malicious data directly to production services. The misconception that a model’s “intelligence” replaces the need for traditional access controls leads teams to embed static service‑account keys in containers or expose Claude’s endpoint to the entire VPC.

Current practice leaves production AI agents unrestricted

In a typical setup, engineers create a service account on GCP, download its JSON key, and bake that credential into the container that runs Claude’s code‑generation service. The container talks straight to Cloud SQL, GKE, or Cloud Storage without any intermediary. Because the credential is static, any compromise of the container – a vulnerable library, a mis‑handled log, or a malicious prompt – instantly grants the agent full production access. There is no audit trail of what the model actually requested, no ability to mask sensitive fields in responses, and no human approval before a destructive operation runs.

Why production access needs more than just identity

Even when the service account is provisioned with least‑privilege scopes, the request still travels directly to the target resource. The identity check happens at the token‑issuance stage, but nothing inspects the payload that reaches the database or the Kubernetes API. The missing piece is a control surface that sits on the data path, where it can evaluate each command, apply real‑time masking, and require just‑in‑time (JIT) approval before the operation is allowed. Without that surface, production access remains a blunt instrument: the model can read or write anything its service account permits, and the organization loses visibility into the model’s actions.

Introducing a gateway in the data path

hoop.dev provides the required gateway. It is a Layer 7 identity‑aware proxy that sits between Claude’s runtime and any GCP resource it needs to reach – Cloud SQL, GKE, Cloud Storage, or other internal services. The gateway authenticates users and agents via OIDC or SAML, reads group membership, and then enforces policies on every request that passes through it.

Setup: identity and provisioning

First, configure an OIDC identity provider (Google Workspace, Okta, or another SAML source). Each Claude instance obtains a short‑lived token that proves who is invoking the model. The token is validated by hoop.dev, which then maps the identity to a set of allowed actions. Service accounts used by the gateway are created with the minimum permissions required for the specific production workloads. This setup determines who may start a session, but it does not enforce what the session can do.

Data path enforcement

All traffic from Claude to the target service is forced through hoop.dev. Because the gateway is the only point where the request is inspected, it can apply fine‑grained controls that would be impossible on the raw network connection. The gateway can block dangerous commands, require an on‑call engineer to approve high‑risk operations, and rewrite responses to mask credit‑card numbers or API keys before they ever reach the model.

Enforcement outcomes

• hoop.dev masks sensitive fields in real time, preventing the model from learning or leaking secrets.
• hoop.dev requires just‑in‑time approval for any command that matches a high‑risk pattern, ensuring a human validates the intent.
• hoop.dev records each session, capturing the full request and response stream for replay and audit.
• hoop.dev blocks disallowed commands before they are executed, reducing the blast radius of a compromised prompt.

These outcomes exist only because hoop.dev occupies the data path. The identity provider alone cannot provide masking or command‑level audit, and the raw GCP service cannot enforce JIT approvals without a proxy.

Getting started

To try this architecture, follow the getting‑started guide. It walks you through deploying the gateway, registering a Cloud SQL connection, and configuring OIDC authentication for Claude. The learn section contains deeper discussions of policy language, masking rules, and approval workflows.

For the full source, contribution guidelines, and issue tracker, visit the GitHub repository. The community welcomes pull requests that add new masking patterns or improve the JIT approval UI.

FAQ

Do I need to change my existing Claude deployment?

No. The gateway works with the same client libraries that Claude already uses. You only need to point the client at the hoop.dev endpoint instead of the direct GCP service address.

Will masking affect the model’s ability to generate correct code?

Masking is applied only to fields identified as sensitive, such as secrets or personal data. The rest of the response remains unchanged, so the model can still produce accurate code snippets.

How does audit replay help with incident response?

Because hoop.dev records the full request/response stream, security teams can replay a session to see exactly what the model asked for, what was approved, and what data was returned. This evidence is valuable for root‑cause analysis and compliance reporting.