Open Protocol
An open protocol for how a human is represented by a persistent AI agent: how that agent is identified, how authority is delegated to it (and to sub-agents beneath it), how permissions and spending limits are enforced, how another system can verify an agent's authority, and how everything is revoked and audited.
PARP is a thin representation and authorization layer, not a replacement for the systems agents already use. It sits above MCP, A2A, and x402, deciding who is acting and what they're authorized to do, while those protocols handle tool access, agent-to-agent messaging, and payment mechanics respectively.
As AI agents start acting on people's behalf, any counterparty needs a neutral answer to three questions before trusting an interaction: who is actually behind this agent, what is it actually authorized to do (not just capable of), and can that authorization be checked and revoked by someone other than the agent itself. PARP's answer is a strict separation between AI reasoning and authority — a signed, revocable, auditable credential chain that no model can grant itself.
Agent Runtime (model reasoning)
│ "I want to do X"
▼
PARP authorize() (deterministic authority — never calls a model)
│
ALLOW │ REQUIRE_APPROVAL │ DENY
▼ ▼ ▼
MCP / A2A / x402 approval flow (stop)The model never talks to MCP, A2A, or x402 directly without this gate. See the specification for the full normative design.
A human's identity moves from unverified to verified through a pluggable third-party identity-verification provider — TradePilot does not build government-ID verification itself. An agent moves through CREATED → UNVERIFIED → ACTIVE ⇄ PAUSED / RESTRICTED → REVOKED / COMPROMISED. An agent is usable in low-risk unverified mode from the moment it's created — full identity verification is only required to cross specific trust boundaries (see Verification).
A verified human has at most one active PrimaryAgentCredential at a time — enforced at the database level, not just by policy. Replacing a primary agent is an explicit, audited sequence: revoke the old credential, invalidate every delegation it issued, rotate keys, and issue a new credential — never an implicit side effect of creating a new agent.
Authority only flows downward: Human → Primary Agent → Delegation Grant → Sub-Agent. A delegated grant's limits must always be equal to or narrower than the issuer's own — never wider. Every authorization check re-walks the full chain from the acting agent to its root primary agent, because a link anywhere in that chain may have been revoked since the sub-agent was created. A sub-agent structurally cannot escalate its own authority: it never has a write path to its own grant or delegation records.
Every sensitive action passes through one deterministic call: authorize(human, agent, action, resource, context) → ALLOW | DENY | REQUIRE_APPROVAL, with a reason, the matched grant, relevant limits, and an approval requirement where applicable. Permissions compose from access, action type, monetary/category/contact/time/geography limits, and an approval mode (always / above a threshold / automatic under a limit / blocked). Three starting presets — Cautious, Balanced, Autonomous — set sensible defaults that a user can then customize grant-by-grant.
Any counterparty can ask a signed, current question about an agent's authority — identity, primary-agent status, delegated authority, action authorization, or revocation status — without an ongoing relationship with that agent. Responses never include the human's name or contact details by default, and are never presented as more certain than their stated confidence and expiry allow.
Every implementation exposes pause (reversible), revoke (terminal for that identity), revoke-a-single-permission, disconnect-a-service, and a dedicated disable-payments control that overrides every purchase-class grant at once. Revocation and audit records are append-only.
Signed credentials with rotatable keys, replay-protected single-use approval tokens, no client-side wallet key exposure, no TradePilot custody of user funds, a hard boundary between the model's reasoning and the permission engine's authority, SSRF-safe handling of any agent-triggered network request, server-side enforcement of every grant/credential mutation, and append-only audit integrity. Full detail in the specification.
MCP is the tool-access layer. Having a connected MCP tool grants capability, not authority — a separate PermissionGrant is required before any specific MCP tool call is allowed to run.
A2A is the agent-to-agent communication layer. PARP lets a signed authority context travel alongside an A2A message so a receiving agent or business can determine identity, verified status, and authorization scope without a separate lookup, while never exposing unnecessary personal information.
PARP decides whether a payment is authorized; x402 decides how the payment itself happens. TradePilot's existing x402 implementation handles the payment mechanics — PARP gates access to it, the same way it gates any other sensitive tool call.
Worked examples for agent verification, delegation narrowing, an x402 payment flow, an A2A message carrying authority context, and an MCP tool call are published in the protocol repository's /examples directory.
The full normative specification — protocol.md, identity.md, permissions.md, delegation.md, verification.md, revocation.md, and security.md — plus versioned JSON Schemas for every protocol object, live in the protocol repository (see GitHub).
This draft is 0.1.0 and not backward-compatibility-guaranteed. PARP is currently stewarded by TradePilot/Doorplace USA as its first implementer, in the open, with no independent foundation or formal governance process yet.
The protocol specification, schemas, and examples are prepared for publication as an open repository. Check back here for the link once it's public.