Portable Signed Agreements for AI Agents: Contents and Verification

The project behind the seed

The seed is a Show HN post from October 26, 2026 linking to Covenant, whose documentation describes it as the Agentic Agreements Protocol (AAP). The post drew modest attention on Hacker News. Its documentation positions Covenant as a way to agree the work, the cost and what counts as finished between people and agents, with approvals, delivery and next steps in one shared record. It offers hosted MCP tools for drafting, review and search, labels the hosted service a developer pilot, and states that the core implementation is not publicly released.

Two design statements in its docs are worth keeping. First, it separates proposed terms, the approved version, delivery submitted, buyer acceptance and payment observed as distinct facts, and says a changed offer needs a new approval. Second, it is explicit about what a signature proves: it authenticates a statement, and does not establish every fact about delivery quality or custody.

Its public docs do publish an API and tool schema, including a live OpenAPI document, and name Ed25519 for owner approvals; what they do not publish is a portable agreement format or a signature specification, and the full implementation is private during early access. Note also that "AAP" is a crowded acronym, used by unrelated projects. So this page does not describe Covenant's format. It answers the general question instead: what a portable signed agreement for an agent should contain, and how a verifier checks one. The checklist below is our own synthesis, not anyone's standard.

What portable means

An agreement is portable when a party that was not present at signing can verify it without calling the system that created it. That rules out a database row with a signed flag. The record has to carry everything needed to check it: the terms, the signatures over those terms, and enough information to resolve each signer's key.

Portability matters for agents because the verifier is often a stranger. A merchant, a payment processor, a second agent or a dispute adjudicator receives the agreement and has to decide whether to act on it, with no shared account and possibly no network access to the issuer.

What the agreement should contain

Parties and keys. Each party's identifier and the public key that will sign. For the agent, the key it will use when acting, so later actions can be tied to this agreement.

Terms, canonically encoded. Scope, price or budget, asset, deadline, acceptance criteria. Canonical encoding means two verifiers hashing the same terms get the same digest, which is what makes the signature meaningful.

Constraints, if authority is delegated. Maximum amount, allowed counterparties, period limits. These turn a record into a mandate the agent can act under.

Validity window. Not before and not after, so an old agreement cannot be replayed indefinitely.

Unique identifier and version. A nonce or ID so the same agreement cannot be presented twice, and a schema version so verifiers know which rules apply.

References to what it binds to. A hash of the order, invoice or checkout it authorises. Without this, a valid agreement can be attached to the wrong transaction.

Signatures. From every party whose consent the agreement claims.

How a verifier checks it

In order, and failing closed at each step.

1. Parse and version check. Reject unknown schema versions rather than guessing.
2. Signature check. Verify each signature over the canonical terms.
3. Key resolution. Confirm each key belongs to the party named. This is the step most implementations hand-wave: a valid signature from an unknown key proves nothing about who agreed.
4. Freshness. Current time inside the validity window, and the identifier not already used.
5. Revocation. Check whether the signer has withdrawn the agreement or the key, if the scheme supports it.
6. Binding. The referenced hash matches the transaction actually being performed.
7. Constraint check. The action requested falls inside the agreement's limits.

Steps 6 and 7 are where agreements succeed or fail in practice. A correctly signed record attached to the wrong action is the common bug.

Relation to AP2 mandates

Google's Agent Payments Protocol is a specific, published instance of this pattern for purchases. In AP2 v0.2, a Checkout Mandate and a Payment Mandate are SD-JWTs, so the holder discloses only the claims each verifier needs. Both are bound by hash to a merchant-signed Checkout JWT, which is the binding step above. In autonomous mode the user signs an open mandate that includes the agent's public key in a cnf claim, with an expiry recommended, and the agent signs a closed mandate for the specific checkout. That is key binding and delegation in one structure.

The difference is scope. AP2 defines a purchase: one checkout, one payment. A general agreement protocol like the one Covenant describes covers work over time: milestones, delivery, acceptance, revisions. Those need lifecycle states a single purchase does not.