The CRM thinks it is talking to you
The ARISE Playbook’s first failure mode is the one every other failure mode assumes you have already solved – and almost nobody has:
Today, most enterprise AI agents borrow one. They run on an employee’s OAuth token, a shared service account, or a long-lived API key created by whoever built them. The agent has no identity of its own – it inherits one, silently, and the inheritance is invisible to every system it touches. The CRM sees an employee. The data warehouse sees a service account. Nothing sees an agent.
That is not a coverage gap in your IAM programme. It is the absence of a subject. Policy, ownership, and audit all need something to attach to. A borrowed credential gives you none of those. When the Playbook asks whether you actually need ARISE, the second diagnostic is brutal: not how many agents you approved – how many are actually running. Gravitee’s 2026 State of AI Agent Security Report found that only 14.4% of AI agents go live with full security and IT approval. The rest are operating on someone else’s identity.
This is the first of five failure-mode posts in our ARISE series. Identity is the foundation. Without it, runtime enforcement is decorating a ghost.
Three borrowed identities, three lies
The employee’s OAuth grant. Someone in Sales connects Copilot or Claude Cowork to Salesforce with their own login. Every subsequent action – including actions taken when that person is at lunch, or after they have left the company – executes as them. Your IdP’s access review will certify a human. The agent is invisible. SACR calls this the maker identity problem in SaaS agent platforms: the creator’s standing access becomes the runtime identity of everyone who later invokes the agent.
The shared service account. Engineering stood up an integration user for “the bot.” Twelve workflows now use it. Rotation is a coordination problem. Attribution is a coin flip. When something goes wrong, the log says svc-automation. That is not an accountability chain. It is a group alias.
The long-lived API key in the agent config. A Stripe key, a GitHub PAT, an OpenAI secret pasted into an env file or an MCP claude_desktop_config.json. We covered the incident pattern in API token rotation: stolen GitHub OAuth tokens cloned thousands of internal repos because the keys were valid, sitting on disk, and nobody had issued anything narrower. Secrets managers store that secret more safely. They do not give the agent an identity of its own.
The Playbook names the three gaps no runtime control can close if this is how you start:
- Nothing to attach governance to.
- No inheritance rules when one agent delegates to another – the second agent’s identity is whatever the developer wired up.
- No basis for trust. Ask a security team to connect an agent to the ERP, and the answer is usually no – not because the agent is dangerous, but because there is no way to prove what it is, what it was built for, and who is answerable when it goes wrong.
What ARISE means by “agent identity”
For humans and machines, identity is established at provisioning. For agents, the Playbook insists it must be continuously maintained, because the gap between what was provisioned and what is happening right now is where the risk lives. A complete agent identity is four things:
- A verified principal – who authorised this agent, and on whose behalf it is acting in this session.
- An organisational intent baseline – what it was built to do, in enforceable form. (That is the next post.)
- A behavioural context – what it is doing right now.
- An accountability chain – every action traceable to the human authorisation that permitted it.
Gartner put AI Agent Identity on the 2026 Hype Cycle as a high-benefit innovation with two to five years to mainstream adoption. The identity vendors – Okta’s Identity Assertion Grant work, Microsoft Entra Agent ID, the NHI platforms – are building the directory object, the sponsorship workflow, the OAuth grant. That work is necessary. It is not sufficient. A first-class entry in Entra that still presents a shared Stripe key to the payments API has a name in the directory and a borrowed identity on the wire.
OWASP’s agentic guidance lands on the same split we argued in AI agent identity isn’t enough: naming the agent is not controlling it. Least agency starts with a credential the agent actually owns.
Two credentials, not one
The pattern that makes agent identity real at the API layer is the same split we use for humans in a well-run SSO world: the caller proves who they are; the platform talks to the vendor.
Each agent (or each workflow, if you are not ready for per-agent granularity) receives a caller credential – an API key you issued, or a JWT your existing IdP already issues. That credential authenticates to the proxy, not to Salesforce. It is unique, revocable, and visible in every audit row as this agent. When the human leaves, or the project dies, you revoke the caller credential. You do not rotate the organisation’s Salesforce integration and hope you found every paste.
The vendor credential – the OAuth client, the API key, the basic-auth pair – stays vaulted. It is injected on the way out, for that call, and never given to the agent. Rotation is an operator action on one record, not a scavenger hunt through laptops and MCP configs.
Your IdP does not get replaced. It gets composed with. A proxy can require a JWT signed by Okta or Entra, so the verified principal is the same principal your access reviews already understand. RequestRocket is the enforcement hop; Okta remains the identity source. NHI discovery tools still tell you which stale keys exist in the estate. The job they cannot do is stop the agent using a borrowed key tomorrow morning.
Lifecycle is IAM discipline at agent pace
The Playbook’s second ARISE requirement is identity lifecycle management: a credentialed identity with a defined owner, a provisioning date, and a record that survives forking, handoff, and retirement. “This is the piece of ARISE that borrows most directly from existing IAM discipline,” the Playbook says. “The work here is applying that same rigor to identities that are created, changed, and retired at a pace no HR system was ever built to handle.”
On the outbound seam that looks like: create a caller credential when the agent is approved, attach the human owner in metadata your SIEM can join, disable it when the agent is retired, and never share it across agents “just for now.” Deny-by-default on the proxy means a newly issued identity can authenticate and still do nothing until intent is expressed as rules. Authentication without authorisation is how borrowed keys felt convenient in the first place.
What this does not solve by itself
Issuing per-agent caller credentials does not discover the Claude Desktop instance on a laptop in Finance. That is shadow agents and your EDR/MDM. It does not, by itself, stop a permitted-but-unintended call. That is scope collapse. It does not reconstruct a three-hop agent chain unless each hop has its own caller identity – which is exactly why inheritance has to be a rule, not an accident.
It does solve the thing the Playbook says you have to solve first: there is a subject. The CRM can still see a service user if that is how the vendor works. Your logs see an agent. That is the difference between hoping and governing.
Next steps
Audit the keys your agents actually use. Any vendor key in an env file or MCP config is a borrowed identity. Move that key behind a proxy, issue a caller credential per agent, and verify it against the IdP you already run. Then write the intent rules – because an identity without a job description is just a named intern with a master key.
Continue with permitted but not intended, or start for free.