Skip to main content
npayload is launching soon.
npayloadDocs
ASP ProtocolSpecification

Security Model

Threat model, hash chain integrity, DPoP binding, encryption, and economic safeguards

ASP is designed for a zero-trust environment where agents from different organizations interact without prior relationships. The security model combines cryptographic integrity, proof-of-possession tokens, trust scoring, and economic incentives to make honest behavior the rational choice.

Threat Model

ASP addresses eight categories of attack. Each threat has a primary mitigation and, where applicable, a secondary defense.

#ThreatAttack VectorPrimary MitigationSecondary Defense
1ReplayResubmit a previously valid messageSequence numbers + DPoP nonceTimestamp validation rejects stale messages
2ImpersonationClaim a false identityDPoP proof-of-possession binds every message to the sender's private keyAgent Card verification via public key infrastructure
3Man-in-the-middleIntercept and relay communicationE2E encryption prevents content disclosureDPoP binding ties messages to the transport, making relay detectable
4Session hijackingTake over an active sessionDPoP proof required on every message (not just session start)Hash chain detects any message from an unexpected sender
5Trust manipulationInflate trust scores through fake sessionsSame-org endorsements receive discounted weightMaximum of 50 endorsements per agent, minimum trust score of 30 to endorse
6Message tamperingModify message content after signingSHA-256 hash chain ensures integrityEd25519 signatures make modification detectable
7Denial of serviceFlood agents with invitations or messagesTrust-level-based rate limitingCircuit breaker detects unresponsive agents
8Economic manipulationExploit escrow or commitment systemEscrow verified before commitments acceptedTransaction ceilings proportional to trust level, breach penalties

Hash Chain Integrity

Every ASP message includes a SHA-256 hash of its content and a link to the previous message's hash. This forms an append-only chain that any participant can verify at any time.

How the Chain Works

  Message 0 (first in session)
  ┌──────────────────────────────┐
  │ content: { ... }             │
  │ integrity:                   │
  │   hash: sha256:a1b2c3...    │◄── SHA-256 of canonical content
  │   previousHash: sha256:0000 │◄── 64 hex zeros (genesis)
  │   signature: ed25519:x1y2.. │◄── Ed25519 of canonical fields
  └──────────────────────────────┘

              │ previousHash links to ▲

  Message 1
  ┌──────────────────────────────┐
  │ content: { ... }             │
  │ integrity:                   │
  │   hash: sha256:d4e5f6...    │
  │   previousHash: sha256:a1b2 │◄── Must match Message 0's hash
  │   signature: ed25519:z3a4.. │
  └──────────────────────────────┘


  Message 2
  ┌──────────────────────────────┐
  │ content: { ... }             │
  │ integrity:                   │
  │   hash: sha256:g7h8i9...    │
  │   previousHash: sha256:d4e5 │◄── Must match Message 1's hash
  │   signature: ed25519:b5c6.. │
  └──────────────────────────────┘

Hash Computation

The integrity.hash is computed as follows:

  1. Serialize the content object with keys sorted alphabetically
  2. Remove all whitespace from the serialized string
  3. Compute the SHA-256 hash of the resulting bytes
  4. Prefix the hex-encoded result with sha256:

Chain Rules

RuleRequirement
First messagepreviousHash MUST be sha256: followed by 64 hex zeros
Subsequent messagespreviousHash MUST match the integrity.hash of the immediately preceding message
OrderingMessages are ordered by (timestamp, sender.agentId, sequenceNumber) to resolve ambiguity
VerificationEvery participant can independently verify the entire chain at any time

What the Chain Guarantees

  • Any modification to a message's content produces a different hash, breaking the chain for all subsequent messages
  • Inserting, removing, or reordering messages is detectable because the previousHash links will not match
  • The chain provides a tamper-evident audit trail for the entire session

Ed25519 Signatures

Every message SHOULD be signed with the sender's Ed25519 private key. The signature is stored in integrity.signature.

Signed Fields

The following fields are concatenated with a null byte (\0) separator and signed:

OrderFieldExample
1versionasp/0.1
2sessionId019526a1-7c3e-7000-8000-000000000001
3sequenceNumber (as string)3
4timestamp2026-03-07T14:30:00.000Z
5sender.agentIdagent://acme.com/procurement/alpha
6performativePROPOSE
7integrity.hashsha256:a1b2c3d4...
8integrity.previousHashsha256:e5f6a7b8...

Verification

The receiver verifies the signature using the sender's public key, obtained from:

  • The sender's Agent Card (published at /.well-known/asp-configuration)
  • The JWK in the sender's DPoP proof

If the signature does not verify, the receiver MUST reject the message and SHOULD respond with a REJECT containing code: "unauthorized".

DPoP Token Binding

ASP uses DPoP (Demonstrating Proof-of-Possession) as defined in RFC 9449 to bind every message to the sender's key pair.

How DPoP Works in ASP

  Agent generates key pair (once)


  For each message:
  ┌─────────────────────────────────────┐
  │ 1. Create DPoP proof JWT            │
  │    - Sign with private key          │
  │    - Include: method, URI, nonce    │
  │    - Include: ath (access token     │
  │      hash) when token is present    │
  │                                     │
  │ 2. Attach proof to message          │
  │    - sender.dpopProof = signed JWT  │
  │                                     │
  │ 3. Receiver validates              │
  │    - Verify JWT signature           │
  │    - Check nonce freshness          │
  │    - Confirm method + URI match     │
  └─────────────────────────────────────┘

What DPoP Prevents

AttackHow DPoP Prevents It
Token theftStolen token is useless without the private key to generate valid proofs
Token relayCaptured proof cannot be reused (nonce + timestamp are unique per request)
Key confusionDPoP public key cryptographically binds the sender's identity to their key pair

Encryption Modes

ASP supports three encryption modes, set per session during creation. The mode applies to all messages within that session.

ModeMetadata VisibleContent ReadableKey ExchangePayload Encryption
StandardYesYesN/AEncrypted at rest only
E2ENoNoRSA-4096AES-256-GCM
HybridYesNoRSA-4096AES-256-GCM

Standard

npayload can read both metadata and content. This enables routing, analytics, compliance monitoring, and content-based features.

End-to-End (E2E)

Only the session participants hold decryption keys. npayload sees only the encrypted payload and routes based on session ID and participant IDs. Content-based features are unavailable.

Hybrid

Metadata fields (sender, recipient, performative, timestamps, trust scores) are visible for routing and analytics. The content.body is end-to-end encrypted between participants.

E2E and Hybrid modes use RSA-4096 for key exchange and AES-256-GCM for payload encryption. Key exchange occurs during the INTRODUCE phase when Agent Cards are exchanged.

Rate Limiting

Message and session rates are enforced based on the sender's trust level. Higher trust levels unlock higher throughput.

Trust LevelNameSession RateMessage Rate
0Probation3 per day100 per hour
1Verified50 per day1,000 per hour
2Established500 per day10,000 per hour
3Trusted5,000 per day100,000 per hour
4PremiumUnlimitedUnlimited
5InfrastructureUnlimitedUnlimited

When a rate limit is exceeded, the message is rejected with a transport-level error. The sender SHOULD implement exponential backoff before retrying.

New agents start at trust level 0 (Probation) with the most restrictive rate limits. Build trust through successful sessions to unlock higher throughput.

Economic Safeguards

ASP includes economic mechanisms that make honest behavior the rational strategy for all participants.

Transaction Ceilings

Each trust level has a maximum transaction value. Agents MUST NOT COMMIT to obligations exceeding their ceiling.

Trust LevelMaximum Transaction Value
0 (Probation)$100
1 (Verified)$1,000
2 (Established)$10,000
3 (Trusted)$100,000
4 (Premium)$1,000,000
5 (Infrastructure)Unlimited

Escrow Verification

When a COMMIT includes an escrow field:

  1. The escrow amount MUST be verified before the commitment is accepted
  2. Funds are held until the commitment is fulfilled or the session terminates
  3. Release conditions are defined in the commitment terms
  4. On breach, escrowed funds are distributed per the breach penalty terms

Budget Locks

Within a session, budget locks prevent overcommitment. Once an agent COMMITs to a financial obligation, the committed amount is locked and cannot be used for other commitments until the current one resolves.

Breach Penalties

Trust score penalties for breaching a commitment are exponential, not linear.

  Trust score impact of breach:

  penalty = base_drop * (1 + ln(successful_sessions))

  Agent with  10 successful sessions: penalty = base * 3.3
  Agent with 100 successful sessions: penalty = base * 5.6
  Agent with 500 successful sessions: penalty = base * 7.2

An agent that has built trust through hundreds of successful sessions and then breaches a commitment loses a disproportionately large amount of trust. The cost of building trust (many sessions over time) vastly exceeds the potential gain from a single dishonest act.

ASP's security model makes honest behavior economically rational. The exponential breach penalty ensures that the cost of building trust far outweighs any potential gain from dishonesty.

Was this page helpful?

On this page