Exact-Action Authority for AI Agents

1. The problem: capability is not authority

An AI agent can be technically capable of calling a tool, issuing an instruction, changing a record or initiating a transaction without being authorised to do that specific thing. Authentication answers who or what is present. Model governance can address how a system was designed and supervised. Runtime security can restrict environments and tools. None of those controls, by themselves, necessarily prove that a particular consequential action is currently authorised.

The ATG control question is deliberately narrower: is this exact agent allowed to do this exact thing, now, under this exact authority? The answer should be based on current evidence rather than an assumption that an authenticated or generally trusted agent may perform every action available to it.

2. The execution boundary

ATG is positioned immediately before a consequential action crosses from proposal into execution or settlement. Upstream systems may plan, reason, optimise or recommend. Downstream systems may execute tools, payments, procurement actions or other effects. The trust gate sits between those stages and evaluates whether the proposed action satisfies policy and authority requirements.

This allows low-risk actions to have a fast path while higher-risk actions require stronger evidence, Verified Human Authority or refusal. The aim is not to place a human in every loop. It is to make the required authority proportional to the consequence.

3. The control chain

4. Why exact-action binding matters

Broad approvals are vulnerable to interpretation drift. “Refund approved,” “supplier change approved” or “transfer approved” may omit the exact amount, destination, item, account or other fields that determine consequence. ATG treats the protected action fields as part of the authority decision. A canonical action can be digested and referenced by the GatePass so that a changed amount, destination, supplier, account or action type no longer silently inherits the earlier approval.

The public demonstrator uses local cryptographic fixtures to make this behaviour inspectable. It does not claim production key custody, production security certification or a hosted authorisation service.

5. Verified Human Authority is more than an approval flag

A field saying approved=true does not prove that the approving person was currently employed or appointed, authenticated through an organisation-controlled credential, authorised for the exact action, within their amount limit, independent from the requester where required, or accompanied by a second authority where policy demands one.

The Human Authority model therefore treats identity status, authentication evidence, authority scope, separation of duties, second approval, freshness and exact-action binding as separate checks. The design is crypto-agile: current strong authentication can be represented without claiming that today's algorithms are automatically post-quantum safe, and algorithm identifiers and verification policy can be replaced as standards evolve.

6. Refusal is part of the product

A credible trust boundary must show when an action does not pass. ATG therefore treats refusal evidence as a first-class output. Synthetic scenarios include inactive identities, exceeded authority limits, restricted self-approval, missing second approval, changed actions, expiry and replay conditions. The refusal should explain the control that failed without creating an execution receipt for an action that never occurred.

This supports the rule: No proof. No permission. No mandate. No action.

7. Human-readable trust receipt

Machine-verifiable evidence is necessary but not sufficient for customers, reviewers, auditors and accountable managers. The same technical evidence can be rendered into a concise receipt showing the proposed action, agent or workflow, accountable principal, human approver where required, relevant mandate and limits, evidence references, decision, GatePass identifier and execution-match result.

The receipt is an explanation of the control evidence, not a substitute for the underlying evidence. It also does not turn ATG into a regulator, auditor or certification authority.

8. Illustrative application routes

The same execution-boundary model can be applied to different sectors without claiming that one generic policy fits all sectors. In retail and supply chains it can model replenishment, supplier, routing and inventory actions. In public procurement it can model purchase orders, contract variations, goods receipt, invoice approval and payment release. In financial services it can model payments, transfers, customer remediation and other high-impact actions subject to delegated authority and evidence.

Sector-specific law, policy, identity systems, procurement controls, payment infrastructure and operational systems remain external. ATG is the proposed exact-action authority and evidence layer, not a replacement for those systems.

9. What the public demonstrator proves — and what it does not

10. Reviewer test

A reviewer should be able to ask six questions and trace the answers to evidence: What exact action was proposed? Which agent or workflow proposed it? Under whose mandate and authority? Which evidence and policy conditions applied? Why was it allowed or refused? Did the later simulated execution still match the authorised action?

If those questions cannot be answered, the trust claim should remain unverifiable rather than being converted into an assumed approval.

Technical review routes

Open the Evidence & Reviewer route →   Verified Human Authority demo →   Agent Standing demo →   Public GitHub repository →

Agent Trust Gate™ is a local synthetic demonstrator. This reference describes the public control model and current design direction; it is not a production security, compliance or regulatory certification.