Skip to content

// How it works

From Delegated Authority to Independent Verification

How an AI agent's delegated authority is resolved at the source, checked, bound to one transaction and verified by the party that relies on it — which then makes its own decision. A conceptual explanation of the model, not a protocol specification.

  1. 01Resolveauthority from principal-authorized sources · provenance
  2. 02Checkagent ↔ principal binding · delegation chain · scope & limits · approvals · validity & revocation
  3. 03Bindto this exact transaction and its constraints
  4. 04Verifyby the relying party, independently
  5. 05Decideunder the relying party's own policy
  6. 06RecordAuthority Transaction Record

The journey, by actor

Who does what, in order

Step
Principal
AI agent
MidPledge
Relying party
Execution system
00
PrincipalAuthorizes the sources that define its agent's authority
01
AI agentSubmits a consequential external action — not a trusted claim
02
MidPledgeIdentifies the Principal and the applicable authority sources
03
MidPledgeResolves current authority · verifies provenance
04
MidPledgeChecks current state: scope, limits, approvals, validity, revocation
05
MidPledgeBinds authority to the transaction → MP-TX-…
06
Relying partyCalls Verify independently, before acceptance
07
Relying partyAccepts, rejects or requests approval under its own policy
08
Execution systemExecutes outside MidPledge — or does not
09
MidPledgeRecords evidence → Authority Transaction Record

// Live Trust Checkpoint

Checked at the boundary, against the source

When an agent's action crosses an organizational boundary, its authority is checked against the Principal's authorized sources — at the moment the other side needs to rely on it.

Trust domain A · Company A
Principal

Company A

authorizes the sources that define its agent's authority

Authority sources

platform assertions · delegated grants · credentials · policy & approval state

AI agent

Agent-27

states an intended action — not its authority

organizational boundary

Live Trust Checkpoint

MidPledge · at verify time

  • 01Which principal does the agent act for?
  • 02Which sources did that principal authorize?
  • 03Does this action fall within scope?
  • 04Is this counterparty allowed?
  • 05Is the value within limits — or is approval required?
  • 06Is the authority current: fresh, not revoked or expired?
  • 07Does it cover this exact transaction?

Transaction-bound reference

MP-TX-DEMO-7C21

Trust domain B · Organization B
Relying party

Organization B

receives the action and its reference

Independent verify

calls MidPledge itself, with the details it received

Own decision

accept, reject or request approval under its own policy

Analogy, if useful: like checking a visa at a border rather than trusting the traveller's description of it. MidPledge is not an identity-document service and does not issue agent passports.

// Live state

Authority is not static.

Current state is checked when the relying party needs to rely on it. Choose a state — or replay a revocation timeline.

Authority state at verify time

AUTHORIZED

authority_status: active

The source confirms the authority is active and fresh, and the request is within scope.

DENIED means current authority was established and does not permit the action. UNVERIFIABLE means current authority could not be established — it is never treated as authorized.

Interactive example · Sample data

MP-TX-DEMO-5E08 · Agent-27 → Organization B · separate example · revocation timeline

19:10

Transaction created and authorized

AUTHORIZED · v12

19:14

Company A revokes the agent's authority at the source

SOURCE UPDATED · v13

19:15

Organization B calls MidPledge Verify

✕ DENIED · AUTHORITY_REVOKED

Press play to step through the timeline.

// The evidence

Authority Transaction Record

Each transaction ends in one record both sides can point to: what was authorized, what the relying party accepted, what was executed — with digests that make tampering detectable.

  • →The MP Transaction ID is a reference, not an authorization token — holding it grants nothing.
  • →Source and version captured at decision time; append-only timeline.
  • →Durable technical evidence — not automatically a legally binding contract.

Protected fields and binding rules: Developers.

Authority Transaction Record

MP-TX-DEMO-7C21

✓ Executed◆ Integrity verified
Principal
Company A
AI agent
Agent-27
Relying party
Organization B
Action
DATA_RELEASE
Target
dataset Q3 · purpose: audit
Duration
≤ 30 days
Outcome
AUTHORIZEDACCEPTEDEXECUTED
Authority source
Principal-authorized policy source
Authority ID
auth_demo_027 · v12
Constraints
approved recipients · audit purpose · ≤ 30 days · no onward sharing
Approval
not required
Authority status
active
MidPledge decision
AUTHORIZED
  1. 10:41:55Z · Transaction created, authority resolved (v12)
  2. 10:41:55Z · Bound · MP-TX-DEMO-7C21
  3. 10:42:07Z · Organization B verify → AUTHORIZED
  4. 10:42:09Z · Organization B decision → ACCEPTED
  5. 10:44:30Z · Release executed by Company A → EXECUTED
  6. 10:44:31Z · Record sealed
Verified at
10:42:07Z
Tx digest
sha256:demo…c217
Evidence digest
sha256:demo…9e41
Signature ref
sig:demo-key
Integrity
◆ VERIFIED
Illustrative Authority Transaction Record using sample data. Not a legal agreement.

Next: the architecture behind it

The five-layer model and the trust boundaries are set out on Trust & Architecture.

Trust & Architecture