The rule a stateless authorization engine cannot hold
Reading tool arguments is table stakes and getting more common. The harder problem is the rule that depends on what this customer already did, in a different conversation, last week.
There is a comfortable story in agent governance that goes: everyone else checks which tool an agent may call, and we check what is inside the call. It is a good line. It is also, increasingly, not true. Cedar policies on AWS Bedrock AgentCore read tool parameters, and the canonical example in the documentation is a ceiling on a refund amount. If your differentiation is that you read arguments, a hyperscaler has already shipped it and gives it away.
So it is worth being precise about what is actually hard.
Two kinds of rule
The first kind is decidable from the call in front of you. Is this refund under $500. Is this tool on the allow-list. Is this principal permitted to touch this account. Every input the rule needs arrives with the request, so any authorization engine can answer it, and several now do.
The second kind is not decidable from the call at all. Does this prequalification, added to everything else this lead has been prequalified for in the trailing window, cross the exposure threshold. Have there been three cash transactions under the reporting limit in ten days. Has this prescriber hit the prior-authorisation frequency band. The current call is fine in isolation. It is only the history that makes it a problem, and the history is exactly what a request does not carry.
Where the state has to live
For a cumulative rule to hold, the ledger has to be keyed to the entity rather than the session, held server-side, and resolved by the enforcement point at decision time. Not passed in by the agent, because anything the model can author is something the model can get wrong or be talked out of. Not derived from the transcript, because transcripts are lossy and a determined customer can start a new one.
This is not an exotic requirement. It is how the fraud and AML systems these institutions already run have worked for twenty years. Velocity checks, structuring detection, aggregate exposure: all of them reason about an entity over time rather than about one event. The agent era did not remove that requirement. It added a new actor that can trip it faster and more fluently than a person could.
Why it stays hard
Statelessness is a genuinely good property for an authorization engine. It makes the engine horizontally scalable, cacheable, and easy to reason about, which is why the category is built that way. Adding entity-keyed durable state means owning consistency, retention, right-to-erasure, and tenant isolation over that state. It is a different system with different obligations, and it is not something a policy language gets by adding a keyword.
That is the line we think is worth defending, and it is a narrower claim than the one the industry likes to make. Argument-level checks are becoming a commodity. Deciding this action against everything this entity has already done is not.