Mechanism · Agent Federation Protocol · Open standard

Agents from different organizations, coordinating without trusting each other.

AFP is the envelope that lets two organizations' agent systems work together across a network neither side controls. Identity proves itself. Confidentiality is a property of the protocol, not a promise from whoever runs it.

01

Three relationships, and nothing else.

Most federation protocols are directories: agents register, capabilities are advertised, work is matched. That makes the directory's operator a party that sees who is doing what with whom. AFP refuses that shape. It defines only the three relationships that genuinely need a shared wire format.

01

Tenant ↔ tenant

How two organizations coordinate work across the line. The counterparty is already known; there is no open call, no broker in the middle. A direct, end-to-end-encrypted session carries the work.

02

Tenant ↔ operator

How whoever runs the transport confirms the system is healthy and within policy, without ever learning what tenants do. The operator checks proofs, not traffic.

03

Continuity

How an organization's identity and its accumulated relationships survive a move between operators, or a shift to self-hosting. Nothing has to be re-established.

It is not a marketplace, not a registry of agents for hire, not a capability feed. The spec defines the three relationships and refuses the rest.

02

Why it holds.

"We don't look" can be revoked. "We cannot look" you can check.

"We don't look" is a promise the next owner, a subpoena, or a breach can quietly revoke. "We cannot look" is a property you verify by reading the protocol. AFP is built on the second kind.

It requires that whoever runs the transport be structurally unable to reconstruct what tenants do (their work content) or who they coordinate with (the relationship graph). A deployment that hasn't actually wired up the routing that delivers graph privacy cannot claim it, and has to say so.

A platform that holds this under inspection is one you can adopt without making its operator part of your threat model.

03

Identity that proves itself.

No registry, no operator

Each organization carries a self-certifying identifier, backed by its own key-event log and its own witnesses. A counterparty verifies you by checking that log, not by querying a registry and not by trusting the operator to vouch for you.

Every key change commits to the next key in advance, so a stolen key cannot be used to impersonate you going forward. And if you move to a different operator or stand up your own infrastructure, the same identity re-derives and every counterparty relationship travels with it. Nothing has to be re-established.

04

What it sits on.

AFP is the envelope: which proof is requested, in which session, against which counterparty, on which terms. The proofs themselves come from a small stack of open standards underneath it, each one independently checkable.

ZKA Carries the work and any value that moves, in zero knowledge. Also the layer that proves where received work came from, so you can verify a counterparty's result without trusting the sender. zka.dev ↗
ZKC Carries the compliance proofs the operator, or a counterparty, is entitled to check. Prove the regulatory fact, reveal nothing else. zkc.dev ↗
ZKM The optional authorization peer. When an agent spends under delegated authority, ZKM proves the spend sits inside a valid, unrevoked, capped mandate without revealing who granted it. How ZKM works →
KERI Carries identity: the self-certifying key-event logs and witnesses that let a counterparty verify you without a registry. keri.one ↗
AFP The envelope around all four. Lineage and provenance live here and in ZKA, and any platform can run it: the protocol names no operator and privileges none. afp.dev ↗
05

The guarantees have no off switch.

Six commitments are written into the protocol, not bolted on as policy: no privileged predicate provider, minimal disclosure by default, no revocation key, open-source predicates, unconditional exit, and accountable verifiers. They are inherited from the ZKA Freedom Safeguards, so the whole stack reads the same, and a conforming implementation cannot drift into a single-operator, surveillance-by-default posture later without ceasing to conform.

01 · No re-identification

No counterparty, witness, or operator may combine AFP interactions to re-identify you in a way you didn't consent to.

02 · No revocable confidentiality

Confidentiality is a property of the protocol. There is no policy switch that turns it off.

03 · No privileged party

Witnesses, compliance issuers, and transport operators are all plural and substitutable. None is hard-coded.

04 · Open verification

The verification logic for every required proof is open-source and reviewable. SDKs refuse opaque predicates by default.

05 · Minimal disclosure

A session reveals what the work requires and nothing more. Bundling disclosures takes per-item consent.

06 · Verifier accountability

A verifier signs what it asks for, and you keep a receipt of what was demanded, for what declared purpose, and what was answered. Unsigned requests are refused by default.

06

Where it stands today.

Draft v0.3.9 · the specification is the source of truth

The identity model, the operator-blindness requirement in both its content and graph forms, the substrate references, the bilateral session core that named profiles build on, and the six Freedom Safeguards are pinned in the specification. That is what implementations build against.

Graph-level privacy depends on the AFP Federation Mixnet, which is specified but not yet deployed everywhere. Until it is in place for a given deployment, that deployment cannot claim graph privacy, and the protocol requires it to say so.

AFP is the transport. Confidential federation pays wherever organizations need to coordinate work neither side would run on the other’s infrastructure.