Your Agent Works for a Platform. It Should Work for You.

Every agent-to-agent protocol currently in development was designed to serve platform operators, not human principals.

A2A authenticates agents as platform entities. ACP focuses on enterprise workflow interoperability where the principal is the enterprise, not the individual. MCP handles tool-use for a single agent session — it is not a negotiation protocol between agents representing different principals. AgentConnect optimizes for deployment topology, not trust topology.

None of them enforce context minimization at the protocol level. Disclosure is implementation-dependent. None define session ephemerality as a protocol guarantee. All are compatible with token economy monetization. None structurally prevent it.

The trust models are thin. The context controls are voluntary. The session residue is undefined. And the economic model underneath each protocol is cloud compute metering — the same model that turned every previous generation of open standards into a funnel for platform lock-in.

We built something different.

The Principal Agent Protocol

PAP is designed from the opposite direction. The human principal is the root of trust. Every agent in a transaction carries a cryptographically verifiable mandate from that root. Sessions are ephemeral by design. Context disclosure is enforced by the protocol, not by policy. The cloud is a stateless utility invoked by agents, not a relationship that accumulates principal context.

No new cryptography. No token economy. No central registry.

The repo is open source, written in Rust, and you can clone it and run the end-to-end proof of concept right now.

The Trust Model

Human Principal (device-bound keypair, root of trust)
  └─ Orchestrator Agent (root mandate, full principal context)
       └─ Downstream Agents (scoped task mandates)
            └─ Marketplace Agents (own principal chains)

Transactions are handshakes between two mandate chains, not two agents. The orchestrator is the only agent that knows who you are. Every downstream agent knows only what its mandate explicitly permits.

Five constraints are enforced at the protocol level, not the implementation level:

1. Deny by default. An agent can only do what its mandate explicitly permits. No scope means no action.
2. Delegation cannot exceed parent. A child mandate’s scope is bounded by its parent’s scope. A child’s TTL cannot exceed its parent’s TTL. This is verified cryptographically, not by policy.
3. Session DIDs are ephemeral. Both agents generate single-use keypairs for each session. These are not linked to any persistent identity. When the session closes, the keys are discarded.
4. Receipts contain property references only. A transaction receipt records what types of data were disclosed — never the values. Both principals can audit the record. No platform stores it.
5. Non-renewal is revocation. A mandate that isn’t renewed doesn’t need a revocation notice. It degrades progressively — Active, Degraded, ReadOnly, Suspended — and then it stops. The principal sees the degradation, not a surprise cutoff.

Built on Standards That Already Exist

PAP uses no novel cryptographic primitives. The entire protocol stack is built on existing, standardized specifications maintained by bodies without platform capture:

Schema.org describes the what. The protocol governs under what terms. These are kept strictly separate — no Schema.org extensions, no vocabulary pollution.

The Implementation

The Rust implementation ships as four crates in a Cargo workspace with four end-to-end examples. 63 tests. All green.

git clone https://github.com/Baur-Software/pap.git
cd pap
cargo test

The Capture Test

PAP is designed against a specific threat: incumbent platform capture. Every major internet protocol that started with user sovereignty has been captured by the entities with the largest infrastructure footprint. This is not a conspiracy. It is the predictable outcome of letting the entities with the most to lose from a protocol define its implementation.

XMPP was open and federated until the major messaging platforms stopped federating. OAuth was designed for user authorization until it became the mechanism by which platforms accumulated indefinite permission to act on behalf of users. Every open protocol that required an incumbent’s infrastructure to function at scale eventually reflected the incumbent’s interests.

Any proposal that routes principal context through infrastructure owned by incumbent platforms is out of scope, regardless of the cryptographic framing around it.

Explicit non-goals: compatibility with token economy monetization. Enclave-as-equivalent-to-local. Identity recovery through platform operators. Payment mechanisms linkable to principal identity. Central registries for agent discovery. Mandate structures allowing runtime scope expansion. UI standards permitting arbitrary code execution in the orchestrator context. Any extension that trades trust guarantees for adoption ease.

Good feedback makes the protocol harder to capture. Proposals that introduce new trusted third parties, centralize discovery, soften disclosure enforcement, or create compatibility with metering models should be evaluated as potential capture vectors first and protocol improvements second.

What Happens Next

PAP v0.1 is a working architecture specification backed by a working Rust implementation. The protocol flow runs end-to-end across four examples — zero-disclosure search, selective disclosure with SD-JWT, four-level delegation chains, and privacy-preserving payment with continuity. 63 tests cover the full protocol surface. The cryptographic guarantees hold.

The repo is at github.com/Baur-Software/pap. Clone it. Run the tests. Run the examples. Read the code. The protocol is in the types, the constraints are in the compiler, and the trust model is in the signatures.

git clone https://github.com/Baur-Software/pap.git
cd pap
cargo test                        # 63 tests
cargo run --bin search            # zero disclosure
cargo run --bin travel-booking    # selective disclosure
cargo run --bin delegation-chain  # hierarchical trust
cargo run --bin payment           # extensions

If you build agents, the question is not whether your agents can talk to each other. The question is who they answer to.