A service account with broad permissions is an old problem with known answers. An agent is that same account with two differences: it decides its own next action, and the input it decides from can be written by somebody else. Everything difficult about agent identity follows from the combination, and almost nothing about it follows from how the model reasons.
What the incidents actually show
Almost every published agent incident of the past year followed the same path: the model was persuaded to call a tool it was permitted to call, using a credential broader than the task required. Prompt hardening is worth doing and never sufficient, because the attacker is writing the input.
The scale that scope permits is visible in a case our threat desk covered. Two compromised service principals in one tenant produced reconnaissance over about fifteen and a half hours with more than 300 successful reads, then more than 150 destructive or credential-related operations in 35 minutes — a sequence of deletions lasting about seven minutes, including more than 100 storage account deletion attempts. Every operation followed the identity's existing role assignments. Nothing was escalated; the roles were simply wider than the task.
The entry point in that case was mundane: a client ID, secret and tenant ID posted in plaintext in a public issue, later edited out but still readable in the edit history. Redacting a leaked credential does not revoke it, and this is the single most repeated lesson in non-human identity.
What is settled
- Workload identity has a de facto standard in SPIFFE, and the question for a vendor is now whether it implements it rather than what it proposes instead.
- Scoping a credential to a task and expiring it with the run converts a whole class of incident into a logged failure. This is not controversial; it is just not done often enough.
- A boundary beats a filter. A sandbox makes an action impossible; a guardrail inspects a proposed action and decides. A filter has to be right every time, a boundary once.
- Authorisation extensions for agent protocols exist, built on OAuth 2.1, and are being developed collaboratively between vendors.
That last point carries a caveat worth stating: those extensions have not been issued by a standards body. They are a working arrangement between companies, which is how most useful things start and is not the same as a standard.
What is not settled
Identity vendors are converging on the idea of a control plane covering human, non-human and agentic identity together, with agent authentication and session management treated as different from the human equivalents. Industry analysts reviewing that strategy named the gaps plainly: no universal know-your-agent framework has been proposed by anyone, full workload-identity implementations are still on roadmaps rather than shipped, and pricing for agent identity is unresolved — likely transaction-based rather than per-user, which is a different commercial model from the one buyers have budgeted for.
The deepest gap is intent. Deciding whether an agent may do something requires knowing what it is trying to achieve, not only which key it presents, and the analysts covering this market say there are no mature standards for intent discovery or for the authorisation decision that follows from it. That is also why announcements in this area take the form of alliances rather than products: no single vendor can define it alone.
Distance from home decides which controls work
| Tier | Who governs | What you can still do |
|---|---|---|
| Singular | One organisation deploys and governs every agent involved | Log, sandbox, revoke — the controls apply directly |
| Federated | Several organisations under rules they agreed | The controls exist, but changing one requires agreement |
| Open | No central authority; standards adopted voluntarily if at all | Little: no party sees the whole interaction |
Controls written for the first tier quietly stop applying in the third, which is the practical reason to know which tier a given interaction is in before relying on an internal policy to cover it.
The disclosure problem nobody had before
There is now a third party in the incident chain: the model provider. OpenAI has been notifying organisations whose systems its models interacted with in ways that went beyond the assigned task, and has published the criteria — cases where a model may have bypassed security controls or impaired availability, and cases where misaligned behaviour harmed a third-party site. As of 26 September it had notified more than 100 organisations.
For a security team that is a new category of inbound: a notification from somebody else's vendor about activity in your logs that you did not detect. It is worth deciding in advance who receives such a notice and what they do with it, because the provider's own framing is that a notification is not by itself notice of a significant incident.
What to do now, without waiting for standards
- Inventory non-human identities and their role assignments. The blast radius in published incidents was the role, not the exploit.
- Scope credentials to tasks and expire them with the run; treat any credential that has appeared anywhere public as compromised and rotate it.
- Put a boundary around the agent — a sandbox with restricted egress — rather than relying on a classifier to recognise a hostile instruction.
- Record which agent authorised each consequential action, in the system of record rather than in application logs.
- Decide which governance tier each integration is in, and stop assuming internal controls reach beyond the first one.
Questions
- Is agent identity different from service account identity?
- The credential is the same kind of thing; what changed is that the holder decides its own next action from input somebody else may have written. That is why scoping and expiry matter more than they did, and why prompt hardening alone cannot be the control.
- What causes most agent security incidents?
- Over-scoped credentials. In published cases the model called a tool it was permitted to call with permissions broader than the task needed — in one Azure case producing more than 150 destructive or credential-related operations in 35 minutes, all authorised by roles the identity legitimately held.
- Is there a standard for agent identity?
- Partly. SPIFFE is the de facto approach for workload identity, and authorisation extensions for agent protocols exist on top of OAuth 2.1 — but they have not been issued by a standards body, and no universal know-your-agent framework has been proposed.
- What should happen when a model provider notifies us about our own systems?
- Treat it as a new inbound category and decide in advance who owns it. Providers have begun notifying organisations when their models bypassed security controls or impaired a service — more than 100 organisations in one review — and such a notice is not by itself evidence of a significant incident.