Before an AI agent acts for a company, it should prove the principal that appointed it, the exact action and resource in scope, limits and approval conditions, its validity period, and that the authority has not been suspended or revoked.
Identity is only the first question
An agent may have a stable identifier, certificate, workload identity or API credential. Those controls can authenticate the software that made a request. They do not prove which legal or operational principal appointed it, or whether the requested action sits inside that appointment.
The relying party needs a separate authority statement that survives changes to the model, prompt, toolchain and session. The evidence should be inspectable without trusting the agent to describe its own permissions accurately.
Bind the agent to a principal
The authority record should name the principal organisation, the agent or service identity, and the governance process that approved the appointment. Entity corroboration can confirm that the organisation exists, but it does not by itself prove that the person approving the mandate was entitled to do so.
Maker–checker approval, source provenance and an audit record help the organisation show how the appointment entered force. Higher-risk workflows may also require a qualified trust or authentic-source boundary agreed for that deployment.
Make scope explicit
A useful mandate states the permitted action, resource, monetary and aggregate limits, supplier or counterparty restrictions, channel, jurisdiction, validity period, delegation depth and explicit exclusions. ‘Can buy’ is not a policy; ‘may place purchase orders against account 17 up to €25,000 for approved suppliers’ is closer.
Human approval should be a machine-checkable condition. If a threshold or category requires a person to approve, the verifier should require evidence that the approval was recorded rather than accepting a sentence generated by the agent.
Check current status at the moment of action
A credential that was valid yesterday may be suspended, revoked, superseded or expired today. Verification should combine cryptographic checks with the current registered mandate state and the exact version that was issued.
The result should be deterministic for the same verified inputs. When the state cannot be resolved, a high-risk relying party should fail closed or route the request to a defined review path.
Keep governance outside the model
Authority policy should not depend on a prompt the agent can reinterpret. The appointment, limits and approval rules belong in an independently governed system, and the relying party should evaluate them before allowing the tool call or transaction.
This separation also makes revocation practical. Ending one agent’s mandate should not require rewriting prompts across every downstream system, and it should not rely on the agent voluntarily honouring a new instruction.
Retain a decision receipt
A verification receipt should record the request, the checks performed, the result, reason codes and the mandate version used. It should avoid retaining unnecessary disclosed claims while preserving enough evidence to reconstruct why the action was accepted, denied or escalated.
A strong pilot tests one valuable action end to end, including a denied request, a human-approval condition and a revocation or expiry event. That proves the control boundary rather than merely demonstrating an agent that can complete a happy path.
Technical verification is evidence. The relying party remains responsible for its trust policy, contractual controls and legal assessment.