What is Proof-Derived Authorization?
Proof-derived authorization is a security model for AI agents in which every action the agent takes must be cryptographically justified by a verifiable proof of its authorisation chain — from the original human principal down through any intermediate orchestrators — making unauthorised actions mathematically impossible rather than policy-prohibited.
Why It Matters
As AI agents gain access to sensitive systems, the question of who authorised this action becomes critical. Current agent frameworks rely on prompt-based access control: the system prompt instructs the agent not to perform certain actions. Proof-derived authorization replaces that with cryptographic guarantees:
- Eliminates prompt injection as an attack surface: An adversarial prompt cannot instruct an agent to take an action for which a valid proof cannot be constructed. The proof requirement is enforced outside the LLM's context window.
- Enables sovereign AI infrastructure: Enterprises and governments can deploy AI agents with the same auditability requirements as human-operated systems — every action has a signed, timestamped authorization record.
- Prevents agent impersonation: In multi-agent pipelines, a compromised sub-agent cannot forge the authorisation of a higher-level orchestrator without access to the corresponding cryptographic keys.
- Regulatory alignment: Proof chains satisfy the audit trail requirements of financial, healthcare, and defence regulations without requiring additional logging infrastructure.
How It Works
The framework described in Verifiable Agentic Infrastructure (arXiv:2605.11XXX) operates in three layers:
- Root authorisation — A human principal signs an authorisation token specifying a scope (e.g., "read and modify files in /project/src, do not access /etc") using their private key.
- Delegation chain — Each orchestrator layer re-signs the token, potentially narrowing (but never expanding) the scope, before passing it to the next agent. The chain forms a verifiable delegation path.
- Action-time proof verification — Before executing any tool call, the agent's runtime verifies that a valid proof chain exists for that specific action type within the current context. If verification fails, the action is rejected regardless of what the LLM's output says.
Example
A financial firm deploys an autonomous reconciliation agent. The CFO signs a root token granting "read-only access to all accounts, write access to the reconciliation ledger". The token is delegated to the orchestrator, which narrows it to a specific date range and delegates to the reconciliation sub-agent. When the sub-agent attempts to write a corrective entry, the runtime verifies the proof chain in milliseconds. If an adversarial prompt tricks the sub-agent into attempting to transfer funds, the attempt fails immediately because no valid proof chain for "transfer funds" exists — not because a policy says no, but because no such proof can be constructed.