Proof-derived authorization limits what an AI agent can do in your systems. The agent gets no standing admin rights. To do something risky, such as deleting a server, it submits a request: the system records why the action would be allowed, independent checks approve or reject it, and the agent receives a temporary key for that one action. Afterwards you can trace why it was allowed.
Where does the term come from?
Jun He and Deying Yu of the company OpenKedge introduced it in May 2026 in Verifiable Agentic Infrastructure: Proof-Derived Authorization for Sovereign AI Systems. Their starting point is that cloud systems grant access by identity: whoever holds valid credentials may run every command those credentials allow. An AI agent can produce commands that are technically valid but unsafe, so standing permissions become a risk. The authors see that risk as most serious in "sovereign" AI systems, where agents work with cloud infrastructure, regulated data, financial processes or national digital services. The paper builds on OpenKedge (April 2026), a protocol by the same authors in which agents submit an intent instead of changing systems directly.
How does it work?
The paper's Distributed Trust Framework (DTF) runs four steps in a fixed order:
- Justification Proof: a structured record of the proposed action, the context at decision time, the policies that apply, a risk assessment and the widest scope that may be granted (action, resource, time window and conditions). The "proof" is this record: explicit and machine-readable, so evaluators and auditors can check it again later.
- Consensus: several independent evaluators, such as a policy check, a dependency check, a simulation or a human reviewer, assess the same record. Riskier actions need a larger quorum or human review, and some evaluators can veto.
- Execution Identity: after approval the agent gets a short-lived credential that works only for the approved action, resource and time window, on AWS for example a temporary STS session with a narrow policy.
- Evidence Chain: an append-only log of the record, the assessments, the decision, the credential and the outcome, so an auditor can later replay why the action was allowed. It must be tamper-evident, for example through hash links or signatures; the paper does not prescribe one cryptographic method.
What did the authors measure?
Their prototype, about 4,500 lines of Go on AWS, handled 10,000 synthetic agent actions in a simulated cloud, 2,400 of them unsafe. DTF blocked or escalated all 2,400; a policy check alone let 336 through. Standing credentials exposed an average of 450 resources per role, while each DTF approval covered 1. Auditors reconstructed the decision for 9,991 of the 10,000 actions, against 2,300 with standard audit logs. A decision took 58.3 milliseconds on average. The authors stress that this was a controlled workload and does not show correctness in the open world.
Where are the limits?
- The paper states that DTF does not solve prompt injection inside the agent. It limits what a misled agent can get approved and carried out.
- A proof is only as good as its inputs. With stale context or a wrong policy, it faithfully records the wrong reason.
- Evaluators that share the same data or blind spots protect less than their number suggests.
- It assumes that every risky action really passes through the framework and that the verification layer itself is not compromised.
- It adds delay, storage and operational work, which the authors consider worth it only for high-stakes actions.
Example
The paper's own example is an agent that proposes to terminate (delete) a cloud server. The record lists the target, the network topology, current traffic, the owner, protection tags and any open incident, plus the policies for destructive actions. If the server lies on a dependency path, the risk assessment marks the action as critical. The result is either no permission at all or a credential for exactly that server, that action and that time window, possibly with a condition to check traffic again just before the deletion. In the authors' words, the record replaces a vague claim such as "the instance appears unused".