An agent needs to read your calendar, so you hand it your credentials. It works immediately, which is the problem. That agent can now do everything you can do — send email, delete files, approve expenses — and every action it takes appears in the audit log as you.
When something goes wrong, and eventually it does, there is no way to tell what you did from what the agent did on your behalf while following instructions embedded in a document it was asked to summarise.
What changed in 2026
- Non-human identity became its own category. Security teams stopped treating agents as a variation on service accounts and started giving them distinct identity models with their own lifecycle.
- Delegation chains got explicit. The pattern of "this agent is acting for this user, under this authorisation, for this task" moved into tooling rather than living in application logic.
- Prompt injection made credential scope urgent. Once it was clear that an attacker who controls any part of the context can influence tool calls, over-permissioned agents stopped being a theoretical risk.
- Short-lived credentials became the default recommendation. Long-lived API keys held by agents are now treated the way hardcoded passwords have been for years.
Why borrowed credentials fail
|
Agent uses your credentials |
Agent has its own identity |
| Audit log |
Shows you |
Shows the agent, and who authorised it |
| Permissions |
Everything you can do |
Only what the task needs |
| Revocation |
Revoke your access too |
Revoke the agent alone |
| Blast radius |
Your entire account |
The scoped permission set |
| Compromise |
Indistinguishable from you |
Contained and attributable |
| Rate limits |
Shared with your own use |
Separate and observable |
The audit row is the one that matters most and gets noticed last. Security investigations depend on being able to reconstruct who did what. An agent operating as you destroys that capability permanently — not degraded, destroyed, because the records genuinely do not contain the information.
Scoping to the task
The instinct is to scope permissions to the user: the agent acts for Alice, so it gets Alice's permissions. That is better than a shared admin key and still far too broad.
Scope to the task instead. An agent summarising invoices needs read access to invoices. It does not need write access, does not need other document types, and certainly does not need payment capability — even though Alice has all three.
This matters because agents are manipulable in ways ordinary software is not. A traditional integration does what its code says. An agent does what its context suggests, and its context includes documents, search results, and tool outputs that may be attacker-controlled. The realistic threat model is that some fraction of agent actions will be influenced by content you did not write, and permission scope is what bounds the damage when that happens. Prompt injection defense covers the attack side; scoping is the mitigation that works even when the defence does not.
Practically: one identity per agent role rather than per agent instance, permissions granted per tool rather than per system, and read-only by default with writes as a deliberate exception. AI agent permissions goes deeper on the permission model itself.
Delegation, and keeping the human visible
An agent rarely acts on its own behalf. It acts because someone asked it to, and that chain needs to survive into the logs.
A well-formed record answers three questions: which agent acted, which human authorised it, and under what task scope. Drop any one and accountability breaks. Just the agent tells you a machine did something with no idea why. Just the human is the borrowed-credential problem again.
This gets harder with subagents, where an orchestrator delegates to workers that delegate further. The authorising human must propagate down the chain, and the scope should narrow rather than widen at each hop — a subagent inheriting more permission than its parent is a bug, and it happens when each level authenticates independently rather than passing a constrained credential down.
Short-lived credentials do a lot of work here. A token valid for the duration of one task, scoped to that task, is dramatically less useful to an attacker than a key that works indefinitely. When an injection succeeds — and some will — the difference between a five-minute token and a permanent key is the difference between an incident and a breach.
Common mistakes
- Sharing one agent identity across users. Every action attributes to the agent with no way to reconstruct who triggered it.
- Putting credentials in the prompt or a tool description. Anything in the context window is reachable by whatever else is in the context window.
- Granting the union of everything any agent might need. Permissions accumulate and nothing gets removed.
- No expiry on agent credentials. A leaked permanent key is permanent.
- Logging the agent but not the authorising human. Half a record is not an audit trail.
- Letting subagents authenticate independently. Scope should narrow down the chain, not reset.
- Treating a read-only agent as harmless. Reading is how data exfiltration works; scope reads too.
FAQ
Is a service account good enough?
It is a reasonable starting point and usually too coarse. Service accounts were designed for deterministic software with fixed behaviour. Agents need the delegation context — which human, which task — that a plain service account does not carry.
How do I handle an agent that genuinely needs broad access?
Push the approval to a human for the sensitive subset. An agent that can draft a refund and requires confirmation to issue it has a very different risk profile from one that can issue it directly, and the friction is usually acceptable — human-in-the-loop agents covers where to place those gates.
What about agents calling third-party APIs?
Same principles, harder execution, because you are constrained by what that provider's auth model supports. Where scoped tokens are available, use them. Where only a full-access key exists, keep it server-side behind a tool you control rather than handing it to the agent.
Does this apply to a single-user local agent?
Less urgently, and the audit argument still holds. A local coding agent with your full credentials can do anything you can, and its context includes files and web content you did not write.
Where to go next
For the attack this permission model defends against, read prompt injection defense. For the permission model itself, AI agent permissions, and for the traces that make delegation chains reconstructable, AI agent observability.