A category that did not exist six months ago
SACR – Software Analyst Cybersecurity Research – has given the industry a name for a problem security teams have been circling since agents went into production: ARISE, Agentic Runtime Identity Security Enforcement. The ARISE Playbook, written with aizome, opens with a line that should end a year of vendor positioning:
ARISE is not NHI security renamed. It is not IAM extended to cover AI agents. It is a new category, built for governance challenges that no existing identity framework was designed to address.
Gartner’s 2026 Hype Cycle for Digital Identity put both AI Agent Identity and Intent-Based Access Control at the Innovation Trigger, High benefit, with less than 1% market penetration on the latter. That is not a product announcement. It is an admission that the frameworks we already bought cannot do this job.
We have written before about where ARISE’s six capabilities sit in an architecture. This series is the practitioner version: the five failure modes the Playbook names, the seven requirements it lists, and the stack you actually assemble – identity provider, SIEM, and the outbound control point – if you want ARISE to mean something on Monday morning.
Why the tools you already have keep missing it
Human identity is stable. Machine identity is deterministic. Non-human identity (NHI) extended the machine model to workloads, containers, and bots. Each model works because it was designed for the behaviour of the identity it governs.
Enterprise AI agents break all three at once. They inherit human permissions but act like machines. They choose which of those permissions to use, in what order, based on the task in front of them. The same agent, given the same task, may follow a different path tomorrow – all within its permissions, all for legitimate reasons. And when a supervisor agent delegates to a worker, which invokes a sub-agent, the original human’s authorization context degrades hop by hop until hop three is technically allowed and completely inconsistent with what anyone intended.
Lawrence Pingree, the SACR analyst who helped name the category, put the identity-extension argument bluntly in a fireside with aizome: JIT, SPIFFE, SPIRE, and OAuth 2 were built for a different kind of agent – the kind whose results were expected. They are getting there. They do not do this well.
That is why “we already have Okta” and “we already have Kong” keep failing the same conversation. An identity provider answers who. An inbound API gateway answers who may call the APIs you own. Neither sits on the path where your agent calls Salesforce, Xero, a payments processor, or an MCP server you did not write. We mapped that unowned seam in the 2026 access-control landscape. ARISE is the name for governing it at runtime.
The five failure modes, in one page
The Playbook does not treat IAM and NHI as incomplete. It treats them as architecturally insufficient. Five named failure modes:
- No provisioning model for agent identity. Most agents borrow a human OAuth token, a shared service account, or a long-lived API key. The CRM sees an employee. Nothing sees an agent.
- Scope assumption collapse. Permissions are correct. The action is still wrong – because it was never the purpose for which those permissions were granted.
- Behavioural non-determinism. Anomaly detection built on a stable baseline floods the SOC or gets tuned to catch nothing.
- Chain identity degradation. By hop three, the worker still has a valid identity. It has lost the reason the work was authorised.
- Cross-protocol visibility gaps. A single agent authenticates via OAuth, API keys, and MCP tokens at once. Your IdP sees the login. It does not see what happens after.
Each of those is a later post in this series. The through-line is the same: authentication is one moment. The consequential behaviour is everything that follows, and most of it happens outside your identity stack’s visibility domain.
Runtime is not a dashboard. It is a control point.
SACR’s companion paper, Runtime Security for AI Agents, frames a three-layer model: deterministic governance (what the agent may access), non-deterministic behavioural analysis (what it is doing and why), and non-deterministic governance (dynamic decisions from those signals). The paper is honest that no vendor owns all three equally well. That is not a reason to wait. It is a reason to know which layer you are buying.
Pingree’s analogy is the right one. Perimeter security is the concert gate. Runtime is the people inside the venue with radios. Scanning once a day and getting yesterday’s results is a car alarm that went off yesterday.
The Playbook adds a sharper operational point: an alert is not a control. By the time a notification fires, the agent has already made the call, moved the data, or sent the message. Agents act at machine speed. There is no window between the action and its consequence for a human to step into.
That is why ARISE keeps using the word enforcement. Discovery without a control point is an inventory. Intent without a control point is a paragraph in a register. Logs without a control point tell you what happened; they do not answer whether it was authorised, and they do not stop the next call.
Where RequestRocket sits
RequestRocket is: runtime access control for AI agents and apps calling APIs you don’t own. Every outbound call gets a least-privilege credential, a policy check, and an audit record, with no code changes to the agent or the upstream system.
That maps onto the ARISE stack in a specific way:
- Your IdP (Okta, Entra, Auth0, Cognito) remains the answer to who. Proxy credentials can verify JWTs against that IdP. Agents do not get a parallel identity island.
- The RequestRocket vault stores the vendor key. RequestRocket injects it at call time so the agent never holds the upstream secret.
- Rules, meters, and filters on the proxy are the structured form of organisational intent the Playbook asks for – not a natural-language job description, an evaluable boundary on method, path, volume, and returned data.
- Telemetry is the per-call record SACR’s observability layer needs: which identity, which decision, which upstream, so your SIEM can correlate it with identity events you already collect.
Inbound gateways stay where they belong – in front of APIs you publish. ARISE is about the other direction. If the only policy engine you have is on the way in, you are governing the wrong door.
What this series covers
Eleven posts, one a day. Failure modes first, then the capabilities the Playbook says you actually need, then a scorecard you can take to a CISO conversation without a vendor bake-off.
- Your agent has no identity. It has a borrowed credential.
- Permitted but not intended: scope assumption collapse.
- Why anomaly detection fails for agents.
- Cost is a governance risk: meters catch optimisation drift.
- MCP security is a runtime problem.
- Don’t govern agents with prompts.
- Least privilege for data, not just actions.
- Shadow agents are already in core processes.
- Three steps to start, without boiling the ocean.
- A scorecard against the seven ARISE requirements.
The window the Playbook describes is real. The category is named. Most enterprises have not built the infrastructure it describes. The ones that put a control point on the outbound call this quarter will deploy agents into Finance and CRM with a story they can defend. The ones that wait for the last lap of the vendor race will discover, as Pingree warned, that AI agent speed does not wait for a winning car.
Next steps
If you already have an IdP and a pile of vendor API keys in agent configs, the first ARISE-shaped move is not a platform RFP. Point one agent at a proxy instead of at the upstream, bind that proxy to a JWT your IdP already issues, and deny everything the agent’s job does not require. That is organisational intent in enforceable form.
Read the documentation, or start for free.