Give the agent its own identity, not your credentials
The most common agent setup in teams is also the most dangerous one for audit. The agent runs under your personal login.
Your GitHub token. Your cloud credentials. Your ticket system session. When the agent opens a pull request, merges a change, posts a message, or reads a file, the system records that you did it.
That setup feels convenient because it works on the first try. Your account already has access to everything, so the agent just runs. No new service account, no approval, no waiting.
The problem shows up later, when something goes wrong and you have to answer a simple question. Did a human do this, or did the agent?
If the audit trail cannot separate those two, you do not have an agent control problem. You have an accountability problem wearing an agent costume.
Why shared identity breaks the audit
This is the part that surprises engineers who have never sat through a real incident review. The credential is not the main issue. The attribution is.
When the agent acts under your name, three things break at once.
The audit log loses meaning. Every action looks like human work. A commit, a config change, a tool call, a data read. They all carry your identity. After the fact, nobody can reconstruct which actions came from the agent and which came from you. I have been in incident reviews in financial services where this exact gap turned a twenty-minute question into a three-day forensic exercise. “Did Thomas approve that change, or did the agent decide to make it?” The logs could not say. That is not a technical detail. It is a control failure.
The agent inherits too much. Your account has the access you need to do your whole job. The agent only needs the access for one task. Handing it your token means the agent can touch everything you can touch, including things the task never asked for. Least privilege dies the moment the agent borrows a human login.
You cannot revoke just the agent. When the agent misbehaves, or when someone leaves the team, the obvious response is to disable the credential. But the credential is yours. Disabling it locks you out too. So teams hesitate, or they rotate everything and break a dozen unrelated workflows. Neither response is the clean, scoped revocation a control loop needs.
The agent should be a named, non-human principal
The fix is small in concept and awkward in practice. Stop treating the agent as an extension of a human. Treat it as its own system with its own name, its own scoped credentials, and its own trail.
A working identity record for an agent looks like this:
Agent identity
Non-human principal name:
Credential source: scoped token / OIDC / workload identity
(never a personal access token)
Scope: exact repos, projects, tool actions
Expiry:
Rotation owner:
Must never hold:
Audit
Every action attributed to the agent principal, not a human
Human approver recorded per run
Reason recorded when the agent escalates for wider access
Revocation
Revoke the agent credential without disabling any human
Independent of human joiners, movers, and leavers
Notice what this is not. It is not a new bureaucracy bolted on top of engineering. It is the same identity discipline you already apply to a service account or a CI worker, applied to something that now makes decisions and takes actions inside your systems.
This is where I keep pointing teams at the two books, because they cover opposite halves of the same problem. Claude Code: Building Production Agents That Actually Scale is about the delivery half: scoped work, run records, review packets, and approvals that survive a question. Securing Enterprise AI Agents is about the control half: non-human identity, least privilege, MCP and data boundaries, audit evidence, and the revoke path when something goes wrong. If your team owns both, the Enterprise AI Agents in Production bundle is the cheaper way to get both halves.
The credential discipline that makes identity real
A named principal means nothing if its credentials are sloppy. The credentials are where teams cut corners, because real credential hygiene is slower than pasting a long-lived token into an environment variable.
A few rules that hold up under review.
Use short-lived credentials, not permanent tokens. A token that expires in an hour forces you to fetch it fresh per run. A token that lives for a year is a standing privilege with an agent’s name on it, waiting to leak. Workload identity, OIDC, and scoped deploy keys all let the agent authenticate for the duration of the task and then forget the credential entirely.
Scope to the task, not to your job title. If the run edits one repo and reads one package registry, the credential should allow exactly that. “Admin” and “full repo access” are conveniences, not controls.
Store secrets where secrets belong. In the platform secret manager or the agent runtime, not in a .env file committed to the repo, not in a shell history, not in a screenshot shared in chat. This sounds obvious. It is still the most common finding in any agent security review I have done.
Rotate on a schedule and on offboarding. A credential that nobody rotates is a credential that nobody owns. Rotation is how you prove the identity is still intentional.
A per-run identity line for Claude Code
For a Claude Code run, the identity question is concrete. The agent will touch git, edit files, and possibly run commands. Give it a machine identity scoped to the one repo and the one set of actions the task needs, then write the identity down before the run starts.
This run uses identity:
Credential scope:
Expiry:
Human approver for this run:
If this run needs wider access than the scope above, it must stop and ask:
What this identity must never touch:
That line takes a minute to fill in. It also answers every awkward question a reviewer or an auditor will ask afterward. Who ran this. What the agent was allowed to do. Where it was supposed to stop. Whose name is on the approval.
The run record should carry that identity alongside the diff, the test results, and the rollback note. When those live together, the review packet stops being a code review and starts being an authority review. That is the shift that makes a Claude Code run approvable instead of merely impressive.
The agent should not hold its own credentials either
There is a trap that follows the first fix. Once the agent has its own identity, someone will let the agent manage that identity. The agent creates its own tokens. The agent rotates its own keys. The agent grants itself new scopes when a task seems to need them.
Do not do this.
An agent that provisions its own access is an agent that can widen its own blast radius without a human in the loop. That is the exact pattern a control loop exists to prevent. Credential creation, scope changes, and permission grants are human decisions. The agent can request them. It cannot approve them.
Keep a hard line. The agent acts under a credential. A human owns the credential, the scope, the expiry, and any change to it.
The buyer problem is accountability, not motivation
Most teams do not need another lecture on zero trust architecture. They need to answer one question for one agent today. Does this agent act under its own name?
If the answer is yes, you can scope it, watch it, revoke it, and explain it. The control loop has something to hold onto.
If the answer is no, every agent action is recorded as an unexplained human action. Your incident reviews turn into guesswork. Your least-privilege policy becomes decorative. And the first time something breaks at scale, you will discover that the convenience of borrowing a human login came with a price you only see during the incident.
The convenient setup is the one that fails loudly in a review room. The slightly slower setup, where the agent has its own scoped, named, expiring identity, is the one that holds up.
Start with the credential you keep reusing
Pick the one credential the agent keeps borrowing from a human. Replace it with a scoped, named, expiring one. Wire the audit so the action is attributed to the agent, not to the person who happened to be logged in.
If the weak spot is the engineering loop, the run record, and the review packet, start with Claude Code: Building Production Agents That Actually Scale. Kindle readers can go straight to Amazon: Claude Code on Amazon Kindle.
If the weak spot is identity, least privilege, and the audit trail behind enterprise agents, read Securing Enterprise AI Agents. It is built for teams dealing with non-human identity, MCP and RAG boundaries, scoped data access, and revoke-ready evidence.
If you own both delivery and control, get the Enterprise AI Agents in Production bundle. One book helps the agent ship reviewable work under its own name. The other helps the organization trust the identity behind it.