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.
| # | Threat | Attack Vector | Primary Mitigation | Secondary Defense |
|---|---|---|---|---|
| 1 | Replay | Resubmit a previously valid message | Sequence numbers + DPoP nonce | Timestamp validation rejects stale messages |
| 2 | Impersonation | Claim a false identity | DPoP proof-of-possession binds every message to the sender's private key | Agent Card verification via public key infrastructure |
| 3 | Man-in-the-middle | Intercept and relay communication | E2E encryption prevents content disclosure | DPoP binding ties messages to the transport, making relay detectable |
| 4 | Session hijacking | Take over an active session | DPoP proof required on every message (not just session start) | Hash chain detects any message from an unexpected sender |
| 5 | Trust manipulation | Inflate trust scores through fake sessions | Same-org endorsements receive discounted weight | Maximum of 50 endorsements per agent, minimum trust score of 30 to endorse |
| 6 | Message tampering | Modify message content after signing | SHA-256 hash chain ensures integrity | Ed25519 signatures make modification detectable |
| 7 | Denial of service | Flood agents with invitations or messages | Trust-level-based rate limiting | Circuit breaker detects unresponsive agents |
| 8 | Economic manipulation | Exploit escrow or commitment system | Escrow verified before commitments accepted | Transaction 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:
- Serialize the
contentobject with keys sorted alphabetically - Remove all whitespace from the serialized string
- Compute the SHA-256 hash of the resulting bytes
- Prefix the hex-encoded result with
sha256:
Chain Rules
| Rule | Requirement |
|---|---|
| First message | previousHash MUST be sha256: followed by 64 hex zeros |
| Subsequent messages | previousHash MUST match the integrity.hash of the immediately preceding message |
| Ordering | Messages are ordered by (timestamp, sender.agentId, sequenceNumber) to resolve ambiguity |
| Verification | Every 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
previousHashlinks 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:
| Order | Field | Example |
|---|---|---|
| 1 | version | asp/0.1 |
| 2 | sessionId | 019526a1-7c3e-7000-8000-000000000001 |
| 3 | sequenceNumber (as string) | 3 |
| 4 | timestamp | 2026-03-07T14:30:00.000Z |
| 5 | sender.agentId | agent://acme.com/procurement/alpha |
| 6 | performative | PROPOSE |
| 7 | integrity.hash | sha256:a1b2c3d4... |
| 8 | integrity.previousHash | sha256: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
| Attack | How DPoP Prevents It |
|---|---|
| Token theft | Stolen token is useless without the private key to generate valid proofs |
| Token relay | Captured proof cannot be reused (nonce + timestamp are unique per request) |
| Key confusion | DPoP 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.
| Mode | Metadata Visible | Content Readable | Key Exchange | Payload Encryption |
|---|---|---|---|---|
| Standard | Yes | Yes | N/A | Encrypted at rest only |
| E2E | No | No | RSA-4096 | AES-256-GCM |
| Hybrid | Yes | No | RSA-4096 | AES-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 Level | Name | Session Rate | Message Rate |
|---|---|---|---|
| 0 | Probation | 3 per day | 100 per hour |
| 1 | Verified | 50 per day | 1,000 per hour |
| 2 | Established | 500 per day | 10,000 per hour |
| 3 | Trusted | 5,000 per day | 100,000 per hour |
| 4 | Premium | Unlimited | Unlimited |
| 5 | Infrastructure | Unlimited | Unlimited |
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 Level | Maximum 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:
- The escrow amount MUST be verified before the commitment is accepted
- Funds are held until the commitment is fulfilled or the session terminates
- Release conditions are defined in the commitment terms
- 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.2An 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.
Related
Was this page helpful?