Govern a coding agent

A coding agent on a developer’s machine inherits whatever that shell already holds. There is no server and no gateway between it and the systems it can reach, so the only place to put a control is inside its own tool-call loop.

A coding agent runs commands as the developer. It reads the same environment variables, the same credential files, and the same shell history, and every one of those was provisioned for a person exercising judgment.

The agent has the person’s access without the person’s context. A production database password sitting in an environment variable was fine when a human typed queries against it. The same value reachable by a process that generates its own commands is a different exposure, and nothing in the credential knows the difference.

The blast radius is whatever the developer can do. That is usually far more than the task needed, and the failure is not hypothetical. An agent that misreads a schema and writes a destructive statement is doing exactly what it was built to do, using access nobody intended it to have.

Restricting the agent is the obvious answer and it is also where the problem lives, because every agent ships its own permission system configured in a file on that machine. Whatever controls exist are invisible to the people accountable for them, and they differ per developer.

flowchart LR
    A[Developer shell] -->|"ambient env vars and creds"| B[Coding agent]
    B --> C[Production database]
    B --> D[Internal API]
    B --> E[Shell commands]

• Engineers run agents such as Claude Code against systems that matter
• There is no MCP server and no gateway in the path, so nothing sits between the agent and the Resource
• You want the credential the agent uses to be narrower than the one the developer holds
• You want a record of what the agent did, per session, rather than per developer’s memory

Suppose an engineer asks an agent to investigate a data problem. The agent needs to query the database. What you want is for it to receive a read-only credential scoped to that task, for a destructive statement to be refused before it runs rather than logged after, and for the whole session to be reviewable afterwards.

Where the agent reaches things through an MCP server, the gateway is a better control point because it does not depend on anything installed on the developer’s machine. See Allow one tool, deny the next.

Where the work belongs to a service rather than a person at a keyboard, the agent should hold its own identity instead. See Give an agent its own identity.

Where the control has to survive a developer who does not want it, read the boundaries below before scoping anything. This pattern is a guardrail on a machine the developer administers.

The agent is launched inside a Keycard session, using the CLI, and that session becomes both the credential source and the decision point.

Credentials arrive per tool call rather than sitting in the environment. What the agent receives is scoped to the task, so a read-only database user rather than the developer’s own role, and it is provisioned when the agent asks rather than being present the whole time.

Each tool call is evaluated before it executes. Policy decides allow, refuse, or ask the developer, so a destructive command is stopped ahead of running rather than discovered afterwards, and a sensitive one can require a person to say yes in the moment.

flowchart LR
    A[keycard run] --> B[Coding agent session]
    B -->|"pre-tool-use hook"| C{Policy}
    C -->|allow| D[Tool runs]
    C -->|ask| E[Developer approves in the loop]
    C -->|refuse| F[Blocked before execution]
    B -->|"credential per call"| G[Scoped resource access]

1. The developer signs in and launches the agent through the Keycard CLI, which wraps the agent in a session tied to their identity.
2. Credentials are provisioned as the agent needs them. A request for a Resource becomes a scoped, short-lived credential rather than a value read from the environment.
3. Every tool call is evaluated against policy before it executes. The outcome is allow, refuse, or escalate to the developer for an in-the-loop decision.
4. Refused calls do not run. The decision happens ahead of execution rather than being recorded after the fact.
5. The session and its decisions are reviewable in the Console, so a run can be read in order rather than reconstructed.

The credential the agent holds is narrower than the one the developer holds. A task that needed reads gets reads, and the ambient production credential stops being the thing in reach.

A destructive action is refused rather than reported. The decision happens before execution, which is the difference between a policy and an incident review.

Sensitive work can pause for a person. Routine calls proceed, and the ones you have decided warrant a human get one, in the moment, without turning every action into a prompt.

The session is legible afterwards. What the agent did during a run is reviewable as a sequence rather than assembled from a developer’s recollection.

The enforcement is local, so it is a guardrail rather than a boundary. Everything in the Aside above applies. Design the control so the important half is somewhere the developer does not administer.

Credentials are scoped, and the execution is not isolated. What this gives you is narrower access and a decision before each call. It does not put the agent in a sandbox, so a permitted action still runs with the reach that action has.

The supported path is narrower than the ecosystem. Terminal-based agents on macOS and Linux are the tested route. Other harnesses and other operating systems are worth validating for your own environment before you depend on them.

Policy has to be written and kept current. Deciding which operations are refused, which are allowed, and which need a person is the work, and it is the part that determines whether engineers experience this as a safety net or an obstacle.

On their own machine, yes, and that is the honest answer to give a reviewer. Treat this as the layer that stops mistakes rather than the layer that stops intent. Where a control must survive intent, put the Resource behind something that requires a Keycard credential, so bypassing the local layer does not grant access.

A credential scoped to the task, provisioned when it asks rather than sitting in the environment beforehand. The usual shape is a narrower principal on the same system, such as a read-only database user in place of the developer’s own role, and it is short-lived rather than persistent.

That is a policy question rather than a product one. Routine calls proceed without interruption, and the friction is whatever you choose to require a person for. Teams generally start by observing and refusing only the clearly destructive, then tighten once they can see what agents actually do.

Attempt the destructive action. It is refused before the tool runs, and the decision is in the session record alongside the credential issuances that preceded it. That is a reproducible demonstration rather than an assurance, which is usually what a reviewer is asking for.

They answer different questions at different moments. The gateway decides whether a call may reach a Resource, and it holds regardless of the machine. The session decides whether a call should happen at all, on the developer’s machine, including commands that reach nothing Keycard fronts. Most teams that care about this end up wanting both.

• A data investigation where the agent should read production and never write it
• Infrastructure work where plan is routine and apply requires a person
• An agent with shell access, where the concern is the commands rather than any API
• Onboarding, where a new engineer’s agent should be narrower than their eventual access

The shape is the same each time. An agent running where a person runs, holding what that person holds, with no server in the path to decide anything.

• Control Tool Calls is the build walkthrough, including the in-the-loop approval
• Connect Claude to Resources covers getting credentials into a session without secrets on disk
• Access Policies covers writing the rules these decisions evaluate
• Read an Activity Feed is where to look when a call was refused
• Allow one tool, deny the next is the same question where a server is in the path
• CLI reference covers the commands behind this pattern