Trust architecture

One consequential action. Multiple facts to prove.

Agent Trust Gate separates identity, standing, authority, approval, exact-action proof and execution evidence instead of collapsing them into a single “allow” response.

The architecture

A pre-action trust boundary.

The demonstrator reconstructs the proposed action and checks evidence at the point of consequence. The goal is not to make the agent more persuasive; it is to make authority more verifiable.

01 · Standing

Who is asking?

Prove control of the declared software-agent identity, identify the accountable principal and verify delegation.

02 · Authority

What may it do?

Check mandate, scope, value, counterparty, policy, evidence and required human authority.

03 · GatePass

For which exact action?

Bind current authority to one canonical action digest, freshness window and one-use decision boundary.

04 · Evidence

What actually happened?

Keep the policy decision and any later simulated execution evidence separate and accountable.

P3-M154

Verified Agent Standing

Before an agent can request a GatePass, the demonstrator can require evidence that the requester controls a registered software-agent identity, names an accountable principal and carries a valid signed delegation for the current request.

  • Agent-key challenge evidence
  • Individual or organisation principal
  • Delegation scope and value limits
  • Expiry, revocation and counterparty checks
  • Delegation-depth controls
  • Exact-request binding before GatePass
P3-M153

Verified Human Authority

A stored approval status is not treated as proof that a real authorised person approved the exact action. The demonstrator checks active organisational identity, authentication evidence and current authority for the relevant action and value.

  • Active organisation identity
  • Organisation-controlled authentication evidence
  • Action-type and value authority
  • Self-approval restrictions
  • Optional second approver
  • Exact-action Human Authority Proof
GatePass

Exact-action proof before consequence.

GatePass is the scoped, time-bound, action-specific proof primitive at the centre of ATG. It is intended to express that the trust checks were satisfied for one exact proposed action — not that an agent is trusted forever.

#

Canonical action digest

Authority binds to a canonical representation of the action. Changing the amount, counterparty or other bound detail changes the action and invalidates prior proof.

One-use control

Nonce and replay logic demonstrate a single-use boundary. Replayed proof is refused rather than silently accepted.

T

Freshness

Verifier-owned time and expiry checks prevent stale proof from being treated as indefinitely valid.

!

Fail-closed refusal

Changed action, unknown or revoked key, expired proof and unresolved trust state are designed to refuse in the local demonstrator.

D

Decision receipt

The gate records what it decided and why. An allow decision does not automatically claim that execution happened.

E

Execution receipt

Simulated execution evidence is kept separate so “allowed” and “executed” remain different facts.

Crypto-agile direction

Designed to evolve without false quantum claims.

ATG's Verified Human Authority roadmap keeps algorithm identifiers, key IDs, signature suites and verification policy replaceable. Current passkeys/WebAuthn are valuable phishing-resistant authentication mechanisms but are not described as automatically post-quantum secure.

  • Replaceable signature and verification suites
  • Ability to represent layered or dual evidence
  • Future support for mature standard post-quantum evidence seals
  • No claim of current quantum-safe production deployment
Boundary

Crypto-agile and post-quantum-ready in design direction — not presently claimed quantum-safe.

That distinction matters. The public repository documents future-readiness while preserving accurate claims about what is implemented today.

What ATG is not

Clear boundaries are part of the product.

The corporate presentation does not broaden the implementation claims. The public build remains a local reference demonstrator and reviewer environment.

Not a production proxy

No live agent interception, production middleware, cloud enforcement service or distributed replay store is claimed.

Not a payment system

No real payment, settlement, wallet, banking or checkout authority is executed by the demonstrator.

Not a certification

No legal, regulatory, compliance, security, procurement or safety certification is claimed.

Technical review

Want to challenge the architecture?

Reproducible criticism, integration questions and bounded design-partner discussions are welcome.

Contact us →