Security¶

a2p implements defense-in-depth security with multiple layers of protection.

Security Overview¶

┌─────────────────────────────────────────────────────────────┐
│                    Layer 1: Network                         │
│  TLS 1.3 • WAF • DDoS mitigation                           │
├─────────────────────────────────────────────────────────────┤
│                    Layer 2: Authentication                  │
│  DID-based identity • Signature verification               │
├─────────────────────────────────────────────────────────────┤
│                    Layer 3: Replay Protection               │
│  Timestamp validation • Nonce checking                     │
├─────────────────────────────────────────────────────────────┤
│                    Layer 4: Authorization                   │
│  Consent policies • Scope validation • Purpose checking    │
├─────────────────────────────────────────────────────────────┤
│                    Layer 5: Rate Limiting                   │
│  Per-agent limits • Per-user limits • Global limits        │
├─────────────────────────────────────────────────────────────┤
│                    Layer 6: Data Protection                 │
│  Encryption at rest • Encryption in transit                │
└─────────────────────────────────────────────────────────────┘

Authentication¶

DID-Based Identity¶

All actors (users, agents, entities) are identified by DIDs:

did:a2p:user:local:alice
did:a2p:agent:local:my-assistant
did:a2p:org:local:mycompany

DIDs are:

• Self-sovereign — You control your own identity
• Cryptographic — Backed by key pairs
• Verifiable — Anyone can verify signatures
• Portable — Not tied to any provider

Request Signing¶

All API requests must be signed:

POST /a2p/v1/profile/did:a2p:user:local:alice/memories/propose
Authorization: A2P-Signature 
  did="did:a2p:agent:local:my-agent",
  sig="eyJhbGciOiJFZERTQSJ9...",
  ts="2025-12-25T10:00:00Z",
  nonce="abc123xyz789def456",
  exp="300"
Content-Type: application/json
A2P-Version: 1.0

{...}

Signature Computation¶

signature = sign(privateKey, sha256(
  method + "\n" +
  path + "\n" +
  timestamp + "\n" +
  nonce + "\n" +
  sha256(body)
))

Replay Protection¶

Timestamp Validation¶

Nonce Validation¶

Example Implementation¶

import { createHash, sign } from 'crypto';

function signRequest(privateKey: string, method: string, path: string, body: object) {
  const timestamp = new Date().toISOString();
  const nonce = crypto.randomUUID().replace(/-/g, '');
  const bodyHash = createHash('sha256')
    .update(JSON.stringify(body))
    .digest('hex');

  const message = `${method}\n${path}\n${timestamp}\n${nonce}\n${bodyHash}`;
  const signature = sign('sha256', Buffer.from(message), privateKey);

  return {
    timestamp,
    nonce,
    signature: signature.toString('base64')
  };
}

Rate Limiting¶

Default Limits¶

Per-Operation Limits¶

Rate Limit Headers¶

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1735126800
Retry-After: 60

Key Management¶

Supported Algorithms¶

Key Rotation¶

Keys should be rotated:

• Scheduled: Every 12 months
• On compromise: Immediately
• On personnel change: Within 72 hours

{
  "keyRotation": {
    "gracePeriod": "7d",
    "notification": {
      "method": "webhook",
      "advanceNotice": "24h"
    }
  }
}

Key Recovery¶

Multiple recovery methods supported:

Data Protection¶

Encryption at Rest¶

Encryption in Transit¶

Privacy Protection¶

DID Enumeration Protection¶

Prevent attackers from discovering valid DIDs:

1. Constant-time responses — Same timing for exists/not-exists
2. Consistent errors — Same error message for all "not found" cases
3. Rate limiting — Block scanning attempts

Data Minimization¶

• Only request scopes you need
• Use shortest practical retention
• Delete data when no longer needed

Error Codes¶

Security Best Practices¶

For Agent Developers¶

• ✅ Keep private keys secure (HSM or secure enclave)
• ✅ Rotate keys regularly
• ✅ Use minimum required scopes
• ✅ Implement proper error handling
• ✅ Log access for audit trails
• ❌ Don't log sensitive data
• ❌ Don't store user data beyond stated retention

For Gateway Operators¶

• ✅ Use TLS 1.3
• ✅ Implement rate limiting
• ✅ Maintain nonce cache
• ✅ Regular security updates
• ✅ Monitor for anomalies
• ✅ Regular penetration testing

For Users¶

• ✅ Use strong policies
• ✅ Review consent receipts regularly
• ✅ Revoke unused agent access
• ✅ Keep recovery methods secure
• ✅ Use sub-profiles for sensitive contexts

Post-Quantum Roadmap¶

a2p has a defined path to post-quantum security:

Supported PQ Algorithms¶

Reporting Security Issues¶

Do not report security vulnerabilities publicly.

Email: security@a2p.protocol

Include: - Description of the vulnerability - Steps to reproduce - Potential impact - Your contact information

Response timeline: - Critical: 4 hours - High: 24 hours - Medium: 72 hours - Low: 7 days

Next Steps¶

• Specification: API — API security details
• Legal: GDPR — Privacy compliance