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

Why guardrails matter for Claude coding agents

Imagine an on‑prem installation of Claude that receives a service‑account token capable of writing directly to production repositories. Engineers store that token in a shared secret file, exposing it to every developer. In that state, a compromised agent can inject malicious logic, exfiltrate proprietary algorithms, or silently overwrite critical components. No human ever reviews the code Claude generates before it merges, and every command proceeds unchecked.

What a pure‑setup looks like without a data‑path gateway

Teams often grant Claude a static credential and point the agent straight at the internal Git server. Authentication is handled by the identity provider, but once the token is issued the request bypasses any enforcement layer. The connection travels directly from Claude to the repository, leaving no audit trail of which prompts triggered which commits. Sensitive literals such as API keys appear in clear text, and there is no way to pause a dangerous operation for a human decision. In short, the setup provides identity verification but no guardrails.

Putting hoop.dev in the data path

You deploy hoop.dev as a layer‑7 gateway that sits between Claude and the target service. The gateway runs as a network‑resident agent close to the Git server and authenticates users and agents via OIDC or SAML tokens. After verification, hoop.dev evaluates each request against policy before it reaches the repository.

How hoop.dev enforces guardrails for Claude

hoop.dev masks any field that matches a configured pattern, so it redacts API keys or passwords that Claude tries to write in real time. It blocks commands that match a dangerous‑operation rule, for example attempts to delete an entire branch without approval. When a request matches a high‑risk rule, hoop.dev routes the operation to a just‑in‑time approval workflow, pausing execution until an authorized reviewer consents. hoop.dev records every session that Claude initiates, creating a replayable audit log that shows exactly which prompts produced which commits. The gateway also tags each action with the originating identity, so auditors can trace back every change to a specific token.

Deploying hoop.dev for Claude on‑prem

Start with the getting‑started guide, which walks you through running the gateway in Docker Compose or Kubernetes. You register Claude as a connection, supplying the host and the credential that the gateway will use to talk to the Git server. You configure identity providers such as Okta, Azure AD, or Google Workspace as the OIDC source, allowing hoop.dev to verify tokens without storing secrets itself. After the connection is created, you define guardrail policies in the web UI or via the policy API: patterns to mask, commands to block, and approval thresholds for critical actions. Once policies are in place, Claude’s traffic automatically routes through hoop.dev, and the guardrails become active without any code changes to Claude.

Fine‑tuning guardrails without breaking developer flow

Developers continue to use their familiar Git client or IDE integration. The gateway intercepts traffic transparently, applying masking and approval only where policies require it. You can start with a permissive rule set and gradually tighten constraints as confidence grows. For example, begin by masking only known secret patterns, then add command‑blocking rules for destructive operations, and finally enable approval for any push to the main branch. Each adjustment reflects instantly across all Claude instances because the policy lives in the gateway, not in each agent. For deeper details on policy configuration, see the learning center.

Benefits beyond immediate protection

hoop.dev provides a single source of truth for every Claude‑initiated change, simplifying compliance reporting. You can replay the recorded sessions to demonstrate that no unauthorized code was introduced, satisfying auditors who require evidence of runtime governance. Inline masking ensures that secret leakage never leaves the perimeter, protecting both intellectual property and downstream services that consume Claude‑generated code. Just‑in‑time approvals introduce a human decision point for high‑impact actions, reducing the risk of accidental or malicious damage.

FAQ

Can I integrate hoop.dev with existing CI pipelines?

Yes. Because hoop.dev sits on the network layer, any CI job that interacts with the Git server simply points to the gateway address. The pipeline continues to use the same Git commands, while hoop.dev applies the configured guardrails to each operation.

Does hoop.dev store Claude’s credentials?

No. The gateway holds the credential only for the duration of the connection and never exposes it to Claude or any downstream process. Identity verification occurs against the OIDC provider, and the credential used to talk to the target service is managed by hoop.dev itself.

What happens if a policy violation is detected?

hoop.dev either masks the offending data, blocks the command, or pauses the request for approval, depending on how the rule is defined. The outcome is logged, and the user receives a clear response explaining why the action was prevented.

Explore the open‑source repository on GitHub to get the code, see examples, and contribute to the project.