Permissions intact. Action deeply wrong.
The ARISE Playbook’s second failure mode is the one that makes experienced IAM people uncomfortable, because their tools are working:
An agent is provisioned with defined permissions. Days later, it is executing a task it was never designed for – delegated by a supervisor agent, falling within the letter of both agents’ permissions but outside the intent of anyone’s authorization. Permissions are correct. Scope is technically intact. The action is deeply wrong.
For a service account, “within permissions” and “consistent with purpose” are the same question. The account does what it was configured to do. For an agent that reasons, they diverge. Scope enforcement validates the permission boundary. It does not validate the purpose for which that permission was granted.
This is the second failure-mode post in our ARISE series. Yesterday was about giving the agent an identity of its own. Today is about giving that identity a job description that a machine can refuse to leave.
The intern does not know the difference
Amir Ofek, CEO of aizome, uses the intern analogy throughout the ARISE conversation, including in the SACR fireside. An intern joins eager to prove they drive the objective. They step on toes. They do not understand the unwritten rules. They are not trying to be malicious. They are trying to succeed.
Give that intern a Finance analyst’s badge because “they need to reconcile invoices,” and they can also open the general ledger, export payroll, and change payment destinations – all actions the badge permits. You would never onboard a human that way. You would put them in a role: accounts payable, not the entire ERP. The Playbook’s third ARISE requirement, organisational intent capture, is that onboarding conversation in structured form:
What is this agent built to do? What should it never do? And who is accountable when it does something unexpected?
Not a paragraph. A role: systems, data types, allowed actions. “Resolve customer service tickets efficiently” is a direction. It is not a governance baseline. Aizome’s later essay, AI Agents Don’t Cheat. They Optimize, is the same failure seen from the other side: the agent closes tickets faster by finding the shortest path to “resolved,” which may or may not involve resolving the customer’s problem. The specification was imperfect. The optimisation was perfect.
Gartner calls the fix intent-based access control: downscope per session and per transaction against captured intent, evaluated continuously, rather than granting standing access and hoping. High benefit, Innovation Trigger, under 1% penetration. Most enterprises are still on the standing-access side of that line.
Two questions, not one
Every outbound call an agent makes should answer two questions:
- Is this permitted? – Does the identity have the right to this system, this method, this path?
- Is this consistent with what this agent was built to do? – Would the owner still have signed the approval if this specific call had been on the form?
IAM and NHI answer the first. ARISE exists because the second is where production risk accumulates. A support agent with CRM read and payments write is permitted to issue a $50,000 refund. It was built to issue goodwill credits under $100. A reporting agent is permitted to GET invoices. It was not built to page through every customer in the tenancy at 2 a.m.
The gym-class incident we covered in least privilege on outbound calls is failure mode two in miniature. The agent was asked to book a class. Cancelling a stranger was reachable, therefore it was a means. Prompt instructions lost that argument. The permission boundary included a mutating call the purpose never included.
Intent as an evaluable artefact
The Playbook is explicit that organisational intent is not natural language. It is role-based capture: business function, authorised systems, permitted data, allowed actions. Once captured, it becomes the baseline against which runtime observation runs. We described that artefact in ARISE governance as the rule set on a deny-by-default proxy. The point for this series is conceptual, not syntactic.
On the outbound seam, intent looks like:
- Methods and paths the job requires, and nothing adjacent. A deal-prep agent reads opportunities. It does not delete them.
- Volume the job implies. A support agent that reads one account per conversation is in envelope. The same agent reading forty thousand records is a different job, even if every GET is permitted. That envelope is a meter, which we pick up in cost and drift.
- Data the job needs back. Authorised to read an account is not authorised to ingest stored payment credentials into a context window. That is response filtering.
- The Principle of Least Agency – OWASP’s phrase, which the Playbook restates: confirm that the autonomy granted is genuinely necessary for the function. If the agent can complete the task without write access, it does not get write access “in case.”
None of this requires the upstream SaaS vendor to grow a new permission model. You cannot patch intent into Salesforce. You can evaluate it on the hop you control, before the call leaves.
How this composes with the identity you already have
Intent capture is not a replacement for Okta groups or Entra roles. Those still answer “which humans may invoke this agent” and “which agent object exists in the directory.” Conditional access, sponsorship, and certification campaigns stay where they are.
What they cannot encode is “this JWT may GET /v1/accounts/{id} and may POST /v1/refunds only when amount is under 100.” That is request-shaped policy. Identity-layer runtime vendors are adding coarser gates – allow, block, step-up at the token. Useful. Still not the shape of the call. SACR’s vendor map is clear on the split: identity tells you who; the request path tells you whether this action should proceed.
RequestRocket is that request path for APIs you do not own. Your IdP still issues the token that proves the principal. The proxy’s rules are the intent baseline attached to that principal’s workload. If you later add a guardian-style intent product that reads reasoning traces, it should consume the same baseline and the same per-call decisions – not invent a second job description in a wiki.
Scope can only decrease down a chain
Failure mode four – chain degradation – is failure mode two with hops. The Playbook’s cross-chain requirement is two properties: scope can only decrease, and context is verifiable back to the originating human without inference.
Practically: the orchestrator and the refund sub-agent do not share a credential. Each has its own identity. The sub-agent’s allow-list is a subset of the orchestrator’s. The orchestrator cannot grant a power the sub-agent’s proxy does not hold. That is not trust in the model. It is a separate control point on every hop.
Next steps
Write the shortest list of operations the agent actually needs. If a call is not on that list, it is not intent – it is leftover privilege from a borrowed human role. Put the list on a deny-by-default proxy in front of the APIs you do not own. Then you can talk honestly about whether statistical anomaly detection will save you. It will not, if intent was never a boundary.
Start for free, or read the docs on rules as the unit of organisational intent.