Picture an incident review after a dependency update takes down a customer-facing service on Thursday afternoon. The records are clear: Maya's token opened the pull request, a teammate reviewed and merged it, and the pipeline deployed it under its own service identity.
Then the review reaches the agent-involvement field I proposed in Nobody Pages the Agent, and Maya has to answer from memory. She didn't write the update. She asked a coding agent on her laptop to prepare it. The agent used her token to push the branch and open the pull request.
The review can't see what the agent was allowed to do or which instructions it received. It can't see what else the agent did with Maya's token while it had it. Every record is accurate, but none connects those actions to the agent session that produced the change.
That's what I mean by an agent wearing your badge. A badge reader logs whose badge opened the door, and it has no field for who walked through. The repository records that your token was used, while the agent's participation has to be reconstructed from someone's memory.
In Your Platform Has a New User: The Agent, I focused on the context and capabilities agents need from a platform. Both come with an ownership obligation.
If a platform lets an agent act, it should record whose authority was used, which workload used it, and which run produced the result. It should also be able to stop that access without locking out the person.
The work has four parts: scope the agent's authority, link the evidence across systems, prove you can stop it, and make the supported path easy. The last one decides whether developers use the other three.
Scope the agent's authority
The agent needs an identity of its own and authority sized to the task. A single login blurs together facts that should stay separate. A person or team owns the workflow, and a software workload makes the requests. A specific run carries out the task under authority that came from a person or an approved policy. The change then passes through a reviewer and a deployment identity, and each of them makes a decision of its own. One account name can't carry all of that.
A model or product name can't either. “Claude” or “Codex” may describe part of a tool's configuration, but neither identifies your dependency-update workflow or the run that opened a particular pull request. Swapping the model shouldn't erase the workflow's ownership history.
Naming the workload also keeps accountability where it belongs. Operators get something specific to investigate and restrict, and the people who grant its access, maintain it, and accept its output still own those decisions.
It's tempting to treat an agent like a new hire, with its own badge, a manager, and a periodic access review. That part of the analogy holds up well. An agent workflow needs an identity, an accountable owner, scoped access, and an offboarding plan. The analogy breaks at accountability. An employee answers for their own judgment, while an agent run acts on authority someone delegated for a specific task. One workflow can also run many instances at once, each under a different person's grant. The badge belongs to the workload, while the authority behind each run still traces back to a person.
OAuth 2.0 starts with an older version of this problem. RFC 6749 describes applications holding users' passwords, often gaining excessive access without a way to revoke one application independently. OAuth separates that access from the user's password through tokens with defined scope and lifetime.
A personal access token can improve on password sharing through narrower permissions, expiration, and independent revocation. But without a separate workload and run record, an agent's actions can still appear only as the developer's activity.
The platform should retain both the workload's identity and the source of its authority. RFC 8693, OAuth's token exchange standard, distinguishes impersonation from delegation. Under impersonation, the actor is indistinguishable from the other party in that context. Under delegation, it keeps its own identity while exercising delegated rights. In the RFC's words, “In a sense, A is an agent for B.”
Local tools make that distinction easy to miss. The Model Context Protocol (MCP) authorization specification defines OAuth-based authorization for HTTP transports and directs stdio implementations to retrieve credentials from the environment. An unsandboxed local server typically runs with the permissions of the account that launches it and may also read credential files and cached CLI logins. Sandboxing and restricted permissions matter separately from how credentials arrive.
For machine access without an interactive user, MCP offers an optional OAuth client-credentials extension. Support depends on the clients and servers you run.
The platform decision is which authority the workflow needs. An interactive agent should receive a task-sized grant within the developer's permissions. Scheduled maintenance may need separately approved service authority with an accountable owner.
Enforcement has to happen outside the agent, at a boundary it can't bypass when executing the requested action. For an agent calling tools, that boundary includes the tool service. Writing “no deployment” in the agent's instructions doesn't remove a credential's deployment rights. If a tool acts through a more privileged backend account, it has to check the caller's authority before using that account. Otherwise the narrow grant understates what the agent can reach. This is the classic confused deputy problem.
For OAuth-protected MCP servers, the specification requires validation that an incoming access token was issued for that server. A server must not accept a token intended for a downstream API and simply pass it through. The caller's access to the tool and the tool's access to another service are separate authorization decisions.
Link the evidence across systems
An agent action leaves evidence in several systems, and the platform has to link it into one chain. To see that chain, replay Maya's update through a supported path. Take the dependency-update workflow I proposed in Your Agent Workflow Needs a Release Process. Its worker may prepare a branch and open a review-ready pull request in one repository. The execution environment denies it merge and production access, and the worker has no way to widen its own access. This time Maya asks that worker to do the job, and the platform issues a grant sized to her request.
An operator should be able to retrieve the evidence below afterward. The names and records are illustrative, and the table describes the evidence without prescribing a token format.
| Question | Evidence retained and linked to the action |
|---|---|
| Which workload acted? | Dependency-update worker, supported workflow version 3. |
| Who is responsible for it? | The platform team and its named workflow owner. |
| Under whose authority? | Maya's delegated grant for this task, with a reference to the authorization record. |
| Which execution? | Run run-482, linked to the originating request and its tool actions. |
| What was allowed? | Branch and pull-request operations in one named repository, with no merge or deployment authority. |
| What happened? | Pull request 318, its commit, the verification results, and the tool service's allow and deny decisions. |
The answers in that table come from four systems. The authorization service, agent runner, tool service, and repository each contribute a different part. Collecting those records centrally can help, but it doesn't remove the need to link them or distinguish what each system validated.
Token exchange can cover the delegation part of that chain. Where supported, its actor claim records who is acting for whom, and nested claims can preserve a longer chain. The RFC treats earlier nested actors as informational only and keeps them out of access decisions. The claim gives you a delegation history, and the platform still has to connect that authorization to the run and its result.
In Trust the Gate, Not the Actor, I argued for encoding judgment into gates that run every time. Those gates also have to record which actor they admitted. The runner should assign the run identifier, and the receiving service should record the identity it validated. The platform should bind that run identifier to the authenticated workload and grant, rather than trust a run label supplied by the agent. The agent shouldn't be able to rewrite those records.
Self-reported attribution is a useful hint that still needs confirmation. A co-author trailer doesn't establish which execution produced a change. Treat an agent_id the model supplies about itself as a claim to confirm against records the agent can't edit.
When Maya's teammate reviews and merges the change, that's another decision by another actor. When the pipeline deploys it, that's another action again. Preserve the chain, and resist relabeling every step as something “the agent did.”
The chain still doesn't tell you how much of the code the agent wrote. For that, keep links to the originating task, the relevant run evidence, and the resulting artifacts. Record the degree of agent involvement and human supervision separately, as I proposed in Nobody Pages the Agent. Allow an unknown value when the evidence is missing. A credential can tell you who was authorized, while authorship needs evidence of its own.
Prove you can stop it
A distinct identity helps only if it supports a distinct control decision. If the dependency worker starts opening inappropriate changes, can the platform suspend it without disabling Maya's account? Can it stop the run in progress, prevent new credentials from being issued, and find out whether credentials already issued still work? Those are separate operations.
How quickly revocation takes effect depends on token design, and OAuth's revocation guidance explains the tradeoff. Short token lifetimes limit exposure, while immediate revocation depends on how the resource server checks access. Token exchange doesn't guarantee that revoking one token revokes the tokens derived from it, and the token exchange RFC leaves that behavior to each implementation.
I'd test the supported workflow end to end. First define how quickly its access must stop. Choose a controlled, harmless test action that succeeds before suspension and exercises the same authorization path. Suspend the worker, stop the run, and block new credentials. Then use an already-issued credential to probe the receiving service and measure the time from the stop request until denial. Stopping the runner alone doesn't prove that its credentials have stopped working.
Compare the measured delay with the workflow's required stop window. Recording the delay isn't the same as accepting it. Stopping future access also doesn't undo a change already made, and recovery stays a separate obligation.
Offboarding follows the same discipline. When an owner leaves or a team retires a workflow, review its grants, credentials, running jobs, and replacement owner. Some access may disappear with the person's account, and other access may belong to a service and continue legitimately. OWASP lists improper offboarding as NHI1 in its 2025 non-human identity risks. Its orphaned-identity case is one where the owner departs without a replacement owner and the identity keeps working. The control is knowing which case you have and acting deliberately.
Make the supported path easy
Broad access tends to win when the narrow path is missing or doesn't fit the job. If limited agent access takes three tickets and pasting a personal token takes 30 seconds, developers will learn the 30-second version.
My team learned what happens when the supported path is missing, and I wrote about it in Your Platform Is Teaching Your Engineers. Our break-glass access was audited, and the volume of requests prompted a closer look. We found emergency access handling routine work that had no supported path of its own.
Agent access follows the same pattern, and I'm not exempt. Until recently, my nightly agent routine swept my GitHub repositories from a Mac mini using a personal access token. It merged Dependabot and Renovate pull requests when CI was green, and it pushed fixes to failing branches. I chose the token because the cloud environment's GitHub access was repo-scoped and the routine needed every repository. On GitHub, each of those merges carried my name, and nothing in the account history distinguished the routine from work I did directly.
That was a limitation of the setup I was using. Nothing about the workflow required it to run under my identity, and for long-lived integrations, GitHub recommends using a GitHub App. I've moved the routine to one that authenticates as an app installation, so GitHub now attributes its merges to the app. That gives the routine an identity separate from mine. Tying each merge to the run that produced it still needs a run record.
The risk categories already exist. OWASP's Non-Human Identities Top 10 lists the reverse of this problem, human use of machine identities. People borrow service credentials, and their activity becomes indistinguishable from automation. OWASP's GenAI Security Project also publishes a Top 10 for Agentic Applications, which lists identity and privilege abuse as ASI03. With the categories named, the remaining work is making the controls usable.
I'd start with one recurring workflow and make access setup part of the product. Register its owner, issue a limited grant and a run identifier, and attach the evidence to the result. A stable workload identity with distinct runs may be enough, since not every conversation needs its own permanent account. Where agents delegate work to other agents, preserve the parent-run relationship and apply the same permission ceiling to the delegated task.
Identity and security teams should define the credential and authorization controls with the platform team, and the platform should expose them through supported tools. Workflow owners maintain the scope and respond when behavior changes. That's work to staff, and an acceptable-use policy can't substitute for it.
The objection I take seriously is that this creates more identities to maintain without making agents more reliable. It can, if we stop at registration. A well-identified agent can still produce a bad patch, and limited permissions don't establish correctness. The review, verification, and operational obligations from Your Agent Workflow Needs a Release Process still apply.
There will be gaps. A legacy service may expose only a shared account, and a local tool may lack useful run records. Make those limits visible and narrow the permitted work to match. Claim only the attribution the underlying system can provide.
Keep the record proportionate. Preserve the identifiers, decisions, and artifact references an investigation needs, with appropriate access and retention. Keep credentials out of logs, and resist collecting every private prompt just to make the audit trail look complete.
Give the next reviewer an answer
The improvement I want is testable. Take a completed change from one supported workflow and have someone outside the run reconstruct its authority, execution, and review from retained evidence alone. Then run the stop drill and confirm the receiving service denies access within the required stop window. If either test starts with finding the original developer and asking what probably happened, the workflow still has work to do.
People remain accountable for the decisions they own. The platform owes them an accurate record of what happened under their authority and a working way to stop further access. When the next review reaches the agent-involvement field, Maya's answer should be a link to run-482.
