The audit log says the machine acted. The real question is who meant for it to act.
An engineer uses an automation token to run a one-off maintenance task. The token already has the right access. The work is urgent. The safer path takes longer. Later, an agent uses the same token to approve a sensitive action because the credential still works and the tool accepts it. When the action is questioned, the log shows the non-human identity. It does not show the human intent that first bent the identity out of shape.
The earlier pieces in this series followed stale identities, over-scoped identities, leaked secrets, and reused identities across weak boundaries. This piece looks at the point where accountability itself becomes blurred: humans acting through machine credentials, and agents later inheriting that ambiguity.
The OWASP Non-Human Identities Top 10 for 2025 names the identity-side failure as NHI10:2025 Human Use of NHI. OWASP describes the core problem directly: NHIs are designed for programmatic access, but developers and administrators often use them manually for debugging or maintenance. The result is elevated access, weak accountability, and logs that cannot reliably distinguish people from automation.
In the OWASP Top 10 for Agentic Applications 2026, the nearest agent-side risks are ASI09 Human-Agent Trust Exploitation and ASI01 Agent Goal Hijack. If a human is persuaded to approve a bad action, or an agent’s goal is redirected through compromised context, shared machine credentials make the event harder to interpret after the fact.
The Ambiguous Action
The following is a review model, not a claim about a specific incident. It shows how human use of an NHI can blur the audit trail before an agent ever arrives.
| Step | Actor | Identity used | What happens | What the log can prove |
|---|---|---|---|---|
| 1 | Engineer | Personal identity | Engineer opens an incident ticket. | A person began work. |
| 2 | Engineer | Deployment NHI | Engineer uses an automation token to inspect production state. | The machine identity accessed production. |
| 3 | Engineer | Deployment NHI | Engineer performs a one-off change outside the normal workflow. | The machine identity changed production. |
| 4 | Agent | Deployment NHI | Agent later sees the same token path and uses it for an approved-looking tool call. | The same machine identity acted again. |
| 5 | Reviewer | Audit system | Reviewer investigates the sensitive action. | Intent, approval, and execution are mixed together. |
The problem is not only that the engineer used the wrong identity. The problem is that the system learned to accept an unclear boundary. Human intent, machine authority, and agent execution now share the same credential path.
Once that happens, incident response slows down. Was the action an engineer’s mistake? An agent’s unsafe plan? A compromised token? A human approving something under pressure? A replay of an old emergency path? The logs may contain timestamps and API calls, but not the distinction that matters.
Before and After Break-Glass
Emergency access is real. Systems break. Incidents do not wait for perfect workflow design. But break-glass access should create more accountability, not less.
| Question | Weak break-glass | Accountable break-glass |
|---|---|---|
| Who receives access? | Anyone who knows or can retrieve the NHI secret. | A named human requests temporary access. |
| Which identity performs the action? | A standing service account or shared automation token. | A short-lived, human-bound session or delegated credential. |
| What is the reason? | Stored in chat, ticket comments, or not recorded. | Required justification linked to an incident or change record. |
| What can be done? | Whatever the NHI can already do. | Narrow action set approved for the emergency. |
| How long does it last? | Until someone remembers to clean it up. | Expiration is automatic. |
| What does the log show? | Machine identity acted. | Human requester, approval, delegated authority, tool, resource, and result. |
| Can an agent reuse it later? | Yes, if the credential remains reachable. | No; authority expires and is bound to the approved use. |
The goal is not to eliminate emergency access. The goal is to stop emergency access from becoming the quiet default.
Attested High-Impact Actions
For ordinary reads, a trace may be enough. For high-impact actions, the system should require attestation.
An attested action records more than the tool call. It records the human requester, the agent or automation that proposed the action, the backing NHI, the policy decision, the reason, the resource, the expected effect, and the approval boundary. If the action changes infrastructure, moves money, deletes records, disables controls, sends messages, or grants access, the audit record should explain why that action was authorized.
Without attestation, an agent can make a dangerous action look ordinary. It can present a request in familiar language, cite a ticket, refer to an operational goal, and call a tool with a credential the system already trusts. A human may approve the action because the workflow looks legitimate. Later, the audit log may show only that a trusted identity acted.
That is where ASI09 matters. Human-agent trust exploitation is not only persuasion in a chat window. It is also the design of approval paths where humans are asked to bless actions without seeing the identity boundary underneath them.
What to Measure
The useful review question is not “who has the credential?” It is “can we separate intent, authority, and execution after the fact?”
For each high-impact agent tool, record:
- The human requester, if any.
- The agent or automation that proposed the action.
- The NHI or delegated credential that authorized the call.
- The resource changed or accessed.
- The policy that allowed the action.
- The ticket, incident, or change record that supplied the reason.
- The expiration of any elevated authority.
- The evidence that the action matched the approved scope.
Then test the uncomfortable cases. Can a human still use the NHI directly? Can an agent retrieve the credential from a previous break-glass path? Can a high-impact action run without a human-bound approval? Can a reviewer distinguish “the engineer did this,” “the agent did this,” and “the machine identity did this” without reconstructing the incident from chat messages?
If the answer is no, the system does not have an audit trail. It has a transcript of effects.
What Has to Be True
Humans should not use standing NHIs for manual work. Debugging, maintenance, and emergency response should use human identities or delegated sessions that preserve the human actor in the record.
Break-glass access should be short-lived, scoped, justified, and reviewed. It should expire by design. It should not place a reusable machine credential into a human workflow, and it should not leave behind a path an agent can reuse later.
High-impact agent actions should be attested. The approval record should bind together human intent, agent proposal, backing identity, tool, resource, and expected effect. A log entry that says only “service account performed action” is not enough.
Agent tools should reject ambiguous authority. If a tool cannot determine whether it is being called by an agent, a workload, or a human using an NHI, that ambiguity should be treated as a risk signal, not normal operation.
Incident response should treat human use of NHIs as a first-class event. It is not merely a shortcut. It changes what the organization can know later.
The series began with a stale identity that stayed alive after its purpose disappeared. This installment closes a different loop: ambiguity that remains after an action is complete. Agentic systems make that ambiguity more costly because they can reuse paths that people normalized in emergencies.
The remedy is not to ask humans and agents to be clearer after the fact. It is to make the system preserve the distinction while the action is happening: human intent, machine authority, agent execution.