Architecture
An agent should never borrow your keys
Most agents running in production today log in as a human being. It is the fastest thing to build and the hardest thing to unwind. It is where accountability quietly disappears, and it hands the agent the single most attacked object in the enterprise.
The first agent almost everyone ships authenticates as its author. Someone mints a personal access token, drops it into an environment variable, and the agent inherits every permission that person holds. It works on day one. It is also the single decision that makes everything downstream harder to reason about.
Once an agent is wearing a human's credentials, three things become impossible at once. You cannot tell from the logs whether a person or a process took an action. You cannot revoke the agent without locking out the person. And you cannot give the agent less authority than its author has, which means in practice every agent runs at the maximum privilege of whoever set it up.
An agent that logs in as you is not an agent. It is you, with worse judgment and no memory of why.
Impersonation is a design decision, not a detail
It is tempting to treat this as plumbing to fix later. It is not. Identity is the substrate that every other guarantee rests on. Audit trails are only meaningful if actions have unambiguous authors. Permissions are only meaningful if the thing being permitted is a distinct subject. Rate limits, budgets, suspension, and reversal all need something to attach to. When agents borrow human identities, all of those controls attach to the wrong object.
The failure mode is not dramatic. Nothing breaks. You simply arrive, six months in, at a system where nobody can answer a question that should be trivial: which of these thousand actions were taken by a person, and which were taken by software acting on their behalf?
The credential is the object attackers go after first
There is a second cost to borrowing, and it is not a governance abstraction. A human credential broad enough to run an agent is the most valuable thing an attacker can steal, because it is the thing they already steal most. The 2025 Verizon Data Breach Investigations Report, drawn from more than 12,000 confirmed breaches, found that credential abuse was the single most common way into an organization, ahead of vulnerability exploitation and phishing. In the basic web-application pattern it is not close: 88% of those breaches involved stolen credentials.
This is not hypothetical for agents specifically. In June 2025, researchers disclosed EchoLeak (CVE-2025-32711, rated critical, CVSS 9.3 by Microsoft), the first documented case of prompt injection weaponized for data exfiltration in a production AI system. A single crafted email, with no user interaction, steered Microsoft 365 Copilot into reading internal files and sending their contents to an attacker. The instructions were untrusted. The privileges used to act on them were the ones the assistant had inherited to act on the user's behalf. When the agent's authority is the user's authority, an injected instruction inherits it too.
What a first-class identity actually requires
Treating an agent as its own actor is more than a label on a row. At minimum it needs:
- Its own credential, issued to it and revocable on its own, without disturbing any human account
- Its own permission set, which can be narrower than any person's, and usually should be
- Its own entry in the audit record, so every action has one unambiguous author
- A human owner, so there is always someone accountable for what it does
- A lifecycle: created, granted, exercised, suspended, retired
These are not house rules. The current OWASP Top 10 for LLM Applications lists Excessive Agency as a top-tier risk, and decomposes it into exactly the three failures a borrowed human credential guarantees at once.
| OWASP LLM06 root cause | What it means | What a borrowed human credential guarantees |
|---|---|---|
| Excessive functionality | The agent can reach tools beyond what its task needs | It inherits every integration its author can touch, by construction |
| Excessive permissions | Those tools run with broader rights than the task requires | It runs at the author's full privilege; it cannot be given less |
| Excessive autonomy | High-impact actions proceed without an independent check | Its actions are recorded as the author's, so there is no separate subject to gate, throttle, or reverse |
The owner and the lifecycle matter more than people expect. Anonymous automation is a governance problem, and organizations are bad at governance problems. Automation with a named owner and a defined lifecycle is a staffing problem, and organizations have handled staffing problems for a century. The framing changes what the rest of the company is able to do with it.
The scoping question nobody asks early enough
Real deployments are multi-tenant almost immediately, even inside a single company. An agent built for one team gets borrowed by another. A key minted for one project ends up in a script that touches three. If the credential does not carry its own boundary, that boundary does not exist.
This is the confused-deputy problem, and the API security literature has a name for the shape it takes. OWASP's API Security Top 10 flags broken function-level and object-level authorization precisely because a coarse OAuth scope like read:documents grants a class of access without saying which documents, so a caller with legitimate function access reaches resources it was never meant to. A credential that only knows a permission but not a boundary will eventually be pointed at the wrong tenant, and nothing in the request will object.
The useful shape is a credential that knows what it may reach: bound to a single organization, or to a named set, or deliberately unbounded for an operator who needs it. The point is that the scope is a property of the key, checked on every call, rather than a convention in a runbook that someone will eventually break.
Where this is heading
The assurance frameworks now being written for AI systems keep converging on the same two demands: attribution and reversibility. Show who did what, and show that it can be undone. Both are downstream of identity. A stack that cannot say which actor took an action cannot satisfy either, no matter how good its model is or how careful its prompts are. Every source above points the same way: the DBIR at the credential as the thing worth protecting, OWASP at scoped least-privilege identity, EchoLeak at what inherited authority does the moment an instruction is untrusted.
How we think about it
On Recursiv an agent is a first-class account, not a configuration file. It has its own record, its own owner, its own credential, and its own scope. It can be suspended without touching a person. Every action it takes is attributable to it specifically, and the record of that action is not something the agent itself can rewrite.
None of this is exotic. It is the same set of assumptions any serious system makes about human users, applied to the non-human ones. The mistake the industry made was assuming agents were a feature of an application rather than a class of actor inside it.
Sources
- Verizon. "2025 Data Breach Investigations Report" (credential abuse the most common initial access vector at 22% of breaches, ahead of vulnerability exploitation at 20% and phishing at 16%; 88% of basic web-application breaches involved stolen credentials). verizon.com/dbir
- OWASP. "Top 10 for LLM Applications 2025, LLM06: Excessive Agency" (root causes and the "generic high-privileged identity" anti-pattern; act "with the minimum privileges necessary"). genai.owasp.org
- OWASP. "API Security Top 10 (2023): Broken Function Level Authorization." owasp.org
- EchoLeak, CVE-2025-32711: zero-click indirect prompt injection in Microsoft 365 Copilot, disclosed by Aim Security, June 2025. nvd.nist.gov