Static permissions answer “may this tool be called?” Agentic systems also need to answer “may it be called now, after this sequence, with this evidence?”
Most access-control systems evaluate an action in isolation. A principal can read a record, call an API or update an object if the current request matches a policy.
Agents introduce a temporal problem. The safety of the next action can depend on everything that happened before it.
AWS made that idea concrete in August 2026 with temporal policies for AgentCore: stateful authorisation rules that can enforce workflow sequencing, match a current argument to a previous tool result, require approval before privileged actions and check data freshness.
The broader architectural lesson goes beyond one platform.
Sequence is part of meaning
Consider a supplier-payment workflow.
Any one of these actions may be permitted:
- read a supplier record;
- read an invoice;
- modify payment details;
- release a payment.
But a sequence such as:
modify bank account → immediately release payment
should require a very different policy from:
read invoice → compare contract → propose payment → obtain approval → release
The tool permissions are identical. The meaning of the sequence is not.
Agent governance therefore needs a notion of workflow state.
Preconditions should be machine-checkable
Human procedures often contain sentences like:
“Only approve when the latest due-diligence report has been reviewed.”
In an agent system that rule should become executable evidence:
- due-diligence result ID;
- timestamp;
- source;
- status;
- reviewer or policy;
- relationship to the action being attempted.
The runtime can then reject a privileged operation if the required evidence is missing, stale or unrelated to the current case.
This is stronger than putting the instruction in the system prompt. The prompt tells the agent what it should do. The policy layer decides what it is allowed to do.
Approval is an event, not a boolean
Human-in-the-loop is often implemented as a generic “approved = true” flag. That is too weak for serious workflows.
A useful approval record should answer:
- who approved;
- which exact action;
- against which data snapshot;
- for what amount or scope;
- when it expires;
- whether parameters may change after approval;
- whether a later action has already consumed that approval.
An approval for €5,000 should not silently authorise €50,000 because the agent changed an argument afterwards.
The approval belongs to a state transition.
Rate limits belong next to temporal policy
AWS announced rate limiting alongside temporal controls, which makes architectural sense. A safe individual action may become unsafe when repeated 10,000 times.
For agentic systems, policy should consider:
what × when × after what × how often × on whose behalf
A customer-service agent may be allowed to issue a small credit, but only a limited number per customer, per agent, per day. A security agent may query a sensitive system, but not with unbounded concurrency.
Frequency changes risk.
Design explicit state machines where the business deserves them
Not every agent needs a formal state machine. But high-impact processes benefit from explicit phases:
COLLECT → VERIFY → PROPOSE → APPROVE → EXECUTE → CONFIRM
Each transition can declare:
- required evidence;
- permitted tools;
- authorised identities;
- time limits;
- rollback behaviour;
- audit output.
The model may choose how to gather evidence inside a phase. It should not be free to invent the control sequence.
This hybrid design gives reasoning flexibility inside deterministic governance.
The Lexdatum view
The next generation of guardrails will not be a filter wrapped around a prompt. It will be stateful policy around business actions.
The practical principle is simple:
The runtime should know enough about the workflow to refuse a locally valid action that is globally unsafe.
That is the difference between permissions for software and governance for agents.
Sources
Research note: This analysis is based on public information available on 1 September 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported claims are identified as such. This is not legal, security, financial or investment advice.