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

An off‑boarded contractor’s CI pipeline still contains a Claude‑powered coding assistant that can push changes directly to production repositories. The contractor’s cloud account has been disabled, but the Claude agent continues to run with the same service‑account credentials it inherited. Within minutes the assistant generates a pull request that modifies a critical configuration file, and because no human ever reviewed the change, the alteration lands in the live environment.

This scenario illustrates why AI coding agents need the same guardrails that we apply to human operators. Guardrails are not a nice‑to‑have add‑on; they are a prerequisite for any system that can execute code on behalf of an organization. Without explicit controls, an agent can become a conduit for credential leakage, data exfiltration, or unintended configuration drift.

Why guardrails matter for AI coding agents

Claude and similar large‑language‑model assistants are increasingly integrated into development workflows. They can autocomplete code, resolve merge conflicts, and even submit patches automatically. The power they bring comes with three core risks:

• Unrestricted execution: An agent can run commands that were never reviewed, potentially opening a backdoor or deleting resources.
• Data exposure: Responses may contain secrets, API keys, or personally identifiable information that should never leave the internal network.
• Lack of auditability: Without a reliable record of who (or what) triggered a change, investigations become guesswork.

Guardrails address each of these risks by enforcing policy at the moment a request is made, not after the fact.

Defining the guardrail requirements

From a security‑engineering perspective, the guardrails we need for Claude on GCP are:

1. Just‑in‑time (JIT) access: The agent should receive temporary permission only for the exact operation it is performing, and the permission should expire immediately after the session ends.
2. Human approval workflow: High‑impact commands, such as those that modify IAM policies or write to production databases, must be routed to an approver before execution.
3. Inline data masking: Any response that contains sensitive fields (e.g., service‑account keys) must be redacted before it reaches the agent.
4. Session recording and replay: Every interaction, including the exact request and the masked response, must be persisted for later audit.
5. Credential isolation: The Claude process never sees the raw credential used to reach the target service; the gateway holds it securely.

These controls form a complete guardrail stack, but they only become effective if they are enforced at the point where traffic crosses the boundary between the agent and the underlying GCP resource.

Architectural approach

The first step is to establish a strong identity foundation. Users, service accounts, and AI agents authenticate to the organization’s OIDC or SAML provider (Okta, Azure AD, Google Workspace, etc.). The identity provider supplies a token that conveys who the caller is and what groups they belong to. This setup determines *who* may start a request, but it does not enforce *what* the request can do.

Enforcement must happen in the data path, the network segment that every request traverses before reaching the target service. Placing policy checks in the data path guarantees that no matter how an agent tries to reach the resource (direct TCP, SDK, or internal library), the request is inspected and either allowed, modified, or blocked.

When the data‑path component records a session, applies masking, or requires approval, those outcomes exist solely because the component sits in the path. If the component were removed, the request would flow unfiltered to the target, and none of the guardrails would be present.

How hoop.dev implements the guardrails for Claude

hoop.dev is a Layer 7 gateway that fulfills the data‑path role described above. It runs a network‑resident agent inside the same VPC as the GCP resources Claude needs to reach (Cloud SQL, Secret Manager, Cloud Storage, etc.). When Claude wants to perform an operation, it connects through hoop.dev using the standard client libraries or the built‑in MCP server. hoop.dev validates the OIDC token, maps the caller’s groups to a policy, and then applies the guardrails before forwarding the request.

Specifically, hoop.dev provides the following enforcement outcomes for Claude:

• JIT access: The gateway issues a short‑lived credential on behalf of the agent, scoped to the exact resource and operation. Once the session ends, the credential is revoked automatically.
• Approval workflow: For actions flagged as high‑risk (for example, writing to a production Cloud SQL instance), hoop.dev pauses the request and notifies an approver. The request proceeds only after the approver explicitly authorizes it.
• Inline masking: Responses that contain fields matching configured sensitive patterns are redacted in‑flight, ensuring Claude never sees raw secrets.
• Session recording: hoop.dev logs the full request and the masked response, storing them for later audit. Auditors can replay any session to see exactly what happened.
• Credential isolation: The gateway holds the GCP service‑account key; Claude never receives the raw key, eliminating credential leakage from the agent’s memory.

Because hoop.dev is the sole point where traffic passes, all of these guardrails are enforced consistently, regardless of how Claude is invoked, whether from a CI job, an interactive notebook, or a background daemon.

Getting started

To protect Claude agents on GCP with hoop.dev, begin with the official getting‑started guide, which walks you through deploying the gateway, configuring OIDC authentication, and defining guardrail policies for your AI workloads. The repository on GitHub contains the Docker‑Compose quick‑start and Helm charts for production deployments.

Follow the steps in the getting‑started documentation to stand up the gateway, then use the learn section to explore policy examples specific to AI coding agents.

FAQ

Do I need to modify my Claude client code?

No. hoop.dev works at the protocol level, so Claude can continue using its existing SDKs or CLI tools. The gateway intercepts the traffic transparently.

Can I apply different guardrails per project?

Yes. Policies are expressed in terms of identity groups and resource tags, allowing you to tailor JIT scopes, approval requirements, and masking rules for each GCP project.

How long are session records retained?

Retention is configurable in the gateway’s policy store. You can align it with your organization’s audit‑retention schedule, ensuring evidence is available for the required period.

By placing guardrails in the data path with hoop.dev, you gain confidence that Claude agents act only within the boundaries you define, while retaining full visibility and control over every operation they perform.

The open‑source repository is available on GitHub: https://github.com/hoophq/hoop.