Skip to content

// Trust & Architecture

Neutral by design. Protocol- and platform-agnostic.

MidPledge works at the boundary between delegated authority and relying-party assurance — between an agent's identity and capability on one side, and the relying party's decision and execution on the other. It complements those systems; it replaces none of them.

1

Identity

identity providers

Who is the agent?

2

Access / Capability

IAM · PAM · runtimes

What can it technically reach?

3

Delegated Authority

← MidPledge

What is it legitimately authorized to do on behalf of the Principal?

4

Relying-Party Decision

← assured by MidPledge

Will the external organization accept the action?

5

Execution Enforcement

execution systems

Will the action actually execute?

MidPledge assures authority. It doesn't make the decision.

A relying party still applies its own authorization, fraud, risk, payment, procurement, compliance and execution logic.

MidPledge adds the input it usually can't get on its own: independent, current, transaction-bound evidence of what an agent is authorized to do — resolved from principal-authorized sources, whichever platform or protocol they live in.

// Protocol- and platform-agnostic

Not a closed protocol. A neutral verification layer.

MidPledge is not a proprietary authorization protocol that every party must adopt. Existing evidence — wherever it is issued — can become an input to verification.

The relying party gets one consistent, transaction-specific result, rather than a separate verifier for every platform, credential format, trust framework or delegated-authorization protocol it might meet.

  • Authority Source Adapter Framework — a required architectural element: a trust contract each source must meet (provenance, versioning, freshness, revocation signalling). Specific named adapters are evidence-gated and not claimed here.
  • Proof-of-possession & workload identity binding — required for production and high-assurance use, so a reference can't be replayed by a different workload. The mechanism is not yet specified publicly and is not claimed as available today.

Possible verification inputs — categories

Identity evidence Platform assertions Delegated grants Credentials KYA / intent evidence Policy & approval state Other protocol evidence

MidPledge

resolveverifybindassure
Relying party

one verification interface

Categories only. No specific protocol or vendor is presented as a MidPledge integration.

// Cross-boundary trust

Two trust domains. One verifiable transaction.

Trust domain A
Principal

Company A

Authorized authority sources

authorized by the Principal

AI agent

attempts an external transaction

MidPledge

  1. 1Resolve authority
  2. 2Verify current state
  3. 3Bind transaction
  4. 4Create Transaction ID
  5. 5Produce verifiable evidence

MP-TX-8F21C4A9

Trust domain B
Relying party

Organization B

Independent verify

→ ACCEPT / REJECT

Execution

→ Authority Transaction Record

// Ecosystem

Complements every stack. Replaces none of it.

Authority sources and evidence on one side; relying parties, decisions and execution on the other. MidPledge is the neutral layer in between.

Authority sources · evidence

  • Identity & credential systems
  • AI / agent platforms
  • Enterprise & business platforms
  • Policy & approval systems
  • Delegation & authorization protocols

MidPledge

Delegated Authority
Trust Layer

resolve · verify · bind
assure · record

Relying-party decision · execution

  • Counterparties / relying parties
  • Merchants · SaaS · APIs · data services
  • Payment networks
  • Banks / PSPs
  • Runtime security

Categories, not companies. Ecosystem references do not imply partnerships or operational integrations.

Security principle · fail closed

A false AUTHORIZED is more dangerous than an ordinary failure.

DENIED

Current authority was established — and it does not permit this action: revoked, expired, out of scope, wrong counterparty, over a limit, or a binding mismatch.

UNVERIFIABLE

Current authority could not be established — the source is unreachable, or state isn't fresh enough. Never treated as authorized.

source outage → unverifiable stale state → unverifiable revoked → denied binding mismatch → denied

See it in the live state demo and the Verify Explorer.

// Architectural safeguards

Three groups of safeguards

Source & state

Authority comes from the source, as it is now

  • · Source-resolved, never the agent's claim
  • · Live state and revocation at verify time
  • · Fail closed: DENIED vs UNVERIFIABLE

Transaction & disclosure

Bound to one action, revealing only what's needed

  • · Transaction binding of protected fields
  • · Independent verification by the relying party
  • · Minimum necessary disclosure of internal policy

Roles & evidence

Each party keeps its own job

  • · Principal issues, MidPledge verifies, relying party decides, systems execute
  • · Append-only Authority Transaction Records

// Boundaries

What MidPledge is not

An AI audit serviceAn agent passportA universal identity or IAM systemProcurement orchestrationA payment processor or settlement networkNetwork or packet monitoringRuntime enforcement

It works alongside identity providers, IAM / PAM, agent runtimes, runtime security, enterprise & business platforms, procurement & ERP systems, payment networks, banks, PSPs, fraud systems, execution systems and enterprise policy systems. CAN ≠ MAY →

// For architects

Compact FAQ

Why not let the agent carry a signed authority credential?

Credentials can be valuable inputs — but on their own, a credential the agent carries is a snapshot. It can be stale, over-broad, or replayed against a different transaction. Checking current state at verify time, and binding to the exact transaction, closes those gaps.

Does every counterparty need third-party verification?

Not necessarily. Many interactions will stay bilateral. MidPledge is designed for cases where a relying party wants independent, transaction-bound evidence of authority across a boundary — how widely that need applies is something the market will show.

What does a relying party actually see?

A result for the transaction in front of it — for example AUTHORIZED, AUTHORITY_REVOKED, BINDING_MISMATCH or UNVERIFIABLE — with the authority status and reference it needs, under minimum necessary disclosure.

Is the Authority Transaction Record a contract?

No. It is durable technical evidence of what was authorized, accepted and executed; it is not automatically a legally binding contract. An optional agreement layer may exist separately where legally and contractually appropriate.

If our platform already governs our agents, why add MidPledge?

Internal governance and external assurance answer different questions. Your platform can manage policies, permissions and approvals inside your organization. A counterparty outside it needs evidence it can verify independently — ideally without integrating with your platform specifically. MidPledge gives it that, across platforms.

How does this relate to agent identity?

MidPledge sits on top of whatever identity an agent already has. It is not an identity provider; it answers what the identified agent is authorized to do, for whom, in this transaction.

Technical & ecosystem information

Technical examples and diagrams illustrate MidPledge's trust model. The Authority Source Adapter Framework and proof-of-possession binding are required architecture for production use, not claimed as available today. Ecosystem references do not imply partnerships or operational integrations. Authority Transaction Records provide technical evidence; their legal effect depends on applicable law and agreements.