An agent can hold valid access and still produce an unjustified action. It can also reuse an approval that is no longer valid when it acts. Understanding an incident therefore requires more than identifying the account that called a tool: the request, its authority, the decision and the observed effect must be connected.
In Swarm, I examine this chain through a transition engine, evidence contracts and a per-action control pilot. The objective is to make commitment conditions examinable without presenting existing mechanisms as a globally qualified protection.
First scenario: a mandate is revoked after approval
Consider a payment request prepared under a valid mandate. Approval is recorded for that operation. The mandate is revoked before commitment. A system retaining only an “approved” state could execute an action whose authority has disappeared.
The gap lies between checking a condition and using the result. Authority depends on the state applicable at the point that commits the effect, as well as the historical dossier. A launch-time check cannot qualify every later operation in a process.
A past decision explains what was authorised. It does not replace checking what remains authorised at commitment.
In Swarm’s current Trust core, commitment rechecks the mandate, revocation, validity period and applicable policy revision. It also examines approved state and approval evidence bound to the action’s content. This path has simulated effects; it does not establish a real payment.
Timing matters: revocation applicable before commitment differs from revocation after an effect has already been committed. The latter does not retrospectively undo the operation. If the outcome is unknown, the process must retain uncertainty and establish the effect before deciding recovery.
Changing a beneficiary or another sensitive parameter raises the same need for exact binding. Approval for A does not become approval for B because the agent calls the change minor. The OWASP AI Agent Security Cheat Sheet recommends binding approval to the operation and checking validity in the execution component. This recommendation does not qualify Swarm.
Who does “the agent” identify?
The principal associated with access, logical agent, instance, delegator, requester and approver are different concepts. A role name in a message does not establish authenticated identity. Two identifiers do not establish two independent people either.
The Trust core resolves identities and roles from authentication sources selected by trusted callers. This does not automatically turn a local role into an identified enterprise person, or structurally valid data into attested human approval. Identity integrations and their qualification must remain explicit.
The distinction between authentication and authorisation also appears in NIST SP 800-207. Recognised identity alone does not establish which operations are allowed on a resource in a particular context.
Second scenario: valid authority, false facts
Now consider an agent proposing network access to a server described as belonging to a test environment. The operation is within a mandate. However, the classification comes from an old inventory: the server now hosts a production service. A technically consistent authorisation could weaken isolation that should have remained in place.
A permission check does not automatically discover that error. The target requires a verifiable representation and a reference whose provenance, currency and integrity are assessed. When evidence conflicts, the decision should expose the contradiction rather than let a summary erase it.
Authorisation establishes a condition for acting; it does not guarantee the truth of every reason offered for action.
A digest identifies the old inventory used. It does not make its classification current. A signed source can also be incomplete or wrong. Comparison can establish a defined discrepancy without establishing the full business suitability of a change.
What Swarm makes examinable today
The Rust Trust pilot retains an attributed action, parameters, mandate and decision evidence. At simulated commitment it rechecks applicable authority and binds intent to the operation’s exact data. Validation controls and artifacts form a separate contract: a successful test does not become business approval.
These mechanisms establish neither a production banking or firewall connector nor reliable automatic inventory classification. They do not prove complete authentication of a model provider or human approver. A model response stating “approved” creates none of those facts.
Access-path coverage remains decisive. Refusal in Swarm cannot protect a resource if a tool or process can reach it through another path. The engine alone does not establish global operating system or network confinement.
What evidence should be retained?
Investigation should recover the original request, actual parameters considered, applicable authority and policy, checks performed, decision and known or unknown result. An agent’s assertions must remain distinct from observations made by the execution component.
Swarm’s ordinary logs remain subject to write permissions and retention. Pilot evidence has a defined scope and verification assumptions; it establishes neither a globally immutable journal, qualified timestamping nor general legal evidentiary status. Hashing does not prove the identity of the data producer.
Finally, checking tool calls does not automatically detect a necessary action never requested. Tracking a business obligation requires its own expected events, conditions and evidence. It cannot be inferred from a tool interceptor alone.
The Swarm repository makes these contracts and limits examinable. “Who authorised?” becomes useful when it can be answered for an exact operation in an identified state, without confusing authority, correctness and effect.