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 control has to start with what the agent is handed.

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, rather than the developer’s own role, 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 the credential source.

Credentials arrive when the agent needs them 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.

The session is tied to the developer’s identity and recorded, so what the agent did during a run can be reviewed in the Console afterwards.

flowchart LR
    A[keycard run] --> B[Coding agent session]
    B -->|"credential per request"| C[Keycard]
    C -->|"scoped, short-lived credential"| D[Resource access]
    B -->|"session record"| E[Console]

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. The session is 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.

Credentials are short-lived. What the agent is handed expires on its own, so there is no long-lived secret left in a shell profile or an environment file for the next run to pick up.

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 control 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 record of the session. It does not put the agent in a sandbox or decide which tool calls may run, so anything the scoped credential permits, the agent can do.

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.

Scoping has to be done per Resource. Deciding what a narrower principal looks like for each system, such as a read-only database user, is the work, and it determines how much the agent’s reach actually shrinks.

On their own machine, yes, and that is the honest answer to give a reviewer. Treat this as the layer that narrows 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.

Credentials are provisioned on demand, so the first request for a Resource may prompt the developer to authorize it. After that, the session hands out credentials without interrupting the work.

Look at the session record in the Console. It shows the credential issuances for the run, tied to the developer who started it, which is a reproducible demonstration rather than an assurance.

They answer different questions. The gateway decides whether a call may reach a Resource, and it holds regardless of the machine. The session decides what the agent is holding when it makes the call, on the developer’s machine. Most teams that care about this end up wanting both.

• A data investigation where the agent should read production and never write it
• An agent with shell access, where the concern is which credentials are in reach of the commands it writes
• 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, which should hold less than that person holds.

• Connect coding agents is the build walkthrough: put Keycard between Claude Code or Cursor and its tools, through a Gateway or a Keycard CLI session
• Allow or deny specific tools is the boundary that holds off the developer’s machine, where a Gateway is in the path
• Connect Claude to Resources covers getting credentials into a session without secrets on disk
• Audit Log & Sessions is where to review what the agent did
• Allow one tool, deny the next covers per-tool decisions where a server is in the path
• CLI reference covers the commands behind this pattern