When an AI agent does something it should not, agent identity decides how quickly you can answer three questions: which agent, acting for whom, and with what access. This walkthrough follows one constructed case from alert to resolution. The company, agents and events are invented for illustration.
The setup (constructed)
Harbor Analytics is a made up software company. It runs three agents: a ticket summarizer, a coding agent that opens pull requests, and a release helper that updates dependency versions. Each has its own identity, an owner and scoped access. A policy engine records every call.
10:42: the alert
A rule fires: the release helper has made a call to a storage API it has never used before. The rule is simple: any agent calling a system outside its recorded scope raises an alert.
The on call engineer, Priya, opens the record. It shows the agent's identity, its owner (the platform team), the human who started the task (a developer, Marcus) and the permission used. The permission is a broad storage read role, granted three weeks earlier to help a one off migration and never removed.
Without per agent identity this would read "Marcus read storage". The record instead shows which agent acted and for whom, so Priya does not call the wrong person.
10:50: is it malicious?
Priya checks the call. The agent read a configuration bucket holding deployment settings, not customer data. The task prompt, kept in the record, asked the agent to "check which services use the old library". The agent had decided on its own to read configuration to answer.
Nothing was stolen. But the agent used access it was never meant to have, and a different prompt might have led it somewhere worse. This resembles what OWASP's LLM Top 10 calls Excessive Agency, where a system has more capability than its task needs.
10:55: contain
Priya revokes the agent's storage permission. Because the release helper has its own identity, this affects only it. The summarizer and coding agent continue. She also pauses the helper's current task, with its owner's agreement, so work does not fail halfway.
She records the time from alert to revocation: thirteen minutes. The team's target in drills is under fifteen.
11:30: scope
Priya asks: what else did this agent touch, and does any other agent hold the same grant? She queries the access records for the helper over the last three weeks. It made forty calls to the storage API, all to the configuration bucket. She then lists every identity with the migration role. The coding agent also has it.
NIST SP 800-61 Rev. 3 describes incident response as part of wider cyber risk management, and this is where that shows: the question moves from one alert to a class of problem, standing access left behind after a project.
12:15: fix
The coding agent's role is removed. The platform team reviews all agent permissions and finds two more unused grants. They set an expiry date on every future grant made for a one off task. The MCP security guidance recommends minimal scopes with elevation on demand, and the team adopts that for the storage API: agents start with none and request access through an approval step.
The following week: review
A short blameless review answers four questions. What detected it? A scope rule on the call. What made it fast? Separate identity and a readable record. What slowed us? The grant had no owner or expiry, so no one remembered it. What changes? Expiry on grants, a monthly review of unused permissions and a drill for revocation time.
Notice that no attacker was involved. Most agent incidents will look like this: a capable system with too much access doing something plausible and unwanted.
What the example shows
Per agent identity made attribution immediate and revocation surgical. Records of the permission used explained how the call was possible. The scope rule was simple and effective. And the lasting fix was process: expiry and review for access, not a smarter model.
If the agent had acted through a shared service account, Priya would have had to revoke access for all three agents and guess which one acted. OAuth token exchange, defined in RFC 8693, describes delegation in which both the acting party and the original party are recorded, which is the kind of record that made this case quick.
Where Safeguard fits
Safeguard's agent identity tracks which agent holds what access at what level, which supports the attribution and permission review steps shown here. MCP Guardrail checks MCP calls against policy, and policies and gates apply at build and release. Harbor Analytics is invented and no real customer is described.
What to do
- Give every agent its own identity and a named owner.
- Record the human or system it acts for, and the permission used.
- Alert on calls outside an agent's recorded scope.
- Practice revoking one agent and time it.
- After any alert, check whether other agents hold the same grant.
- Put expiry dates on grants made for one off tasks.
- Review unused permissions monthly.
Quick check
Is Harbor Analytics a real company?
No. It is a constructed example, and the people and events are invented to show the steps.
Why did revoking one agent not disrupt the others?
Because each agent had its own identity. With a shared account, revocation would have stopped all of them.
Sources
- OWASP Top 10 for LLM Applications
- MCP security guidance
- RFC 8693, OAuth 2.0 Token Exchange
- NIST SP 800-61 Rev. 3
Last reviewed: 18 October 2026.
