​

AAP Security Model

​

Purpose of This Document

1. What AAP protects against (and what it doesn’t)
2. Trust assumptions and their failure modes
3. Cryptographic requirements
4. Attack scenarios and mitigations
5. Implementation security guidance
6. Operational security requirements

​

Table of Contents

1. Threat Model
2. Trust Boundaries
3. Security Properties
4. Alignment Card Security
5. AP-Trace Security
6. Handshake Security
7. Verification Security
8. Drift Detection Security
9. Cryptographic Requirements
10. Implementation Security
11. Operational Security
12. Adversarial Analysis
13. What AAP Cannot Protect Against
14. Defense in Depth

​

1. Threat Model

​

1.1 Adversary Classes

• Follows protocol correctly
• May attempt to learn information beyond what’s intended
• Does not fabricate or tamper with data
• AAP provides strong protection

• Follows protocol structure but games content
• Selectively logs favorable decisions
• Declares values it doesn’t implement
• Exploits ambiguities in specification
• AAP provides partial detection, limited protection

• Actively subverts protocol
• Fabricates traces, forges cards
• Colludes with other malicious agents
• Compromises verification infrastructure
• AAP provides minimal protection; out of primary scope

​

1.2 Threats In Scope

​

1.3 Threats Out of Scope

​

1.4 Threat Prioritization

​

2. Trust Boundaries

​

2.1 Trust Boundary Diagram

+---------------------------------------------------------------------------+
|                         PRINCIPAL DOMAIN                                   |
|  +-------------+                                                          |
|  |  Principal  |<--- TRUST: Human judgment, final authority               |
|  +------+------+                                                          |
|         | Escalations, Oversight                                          |
|  =======+==========================================================      |
|         |        TRUST BOUNDARY 1: Principal <-> Agent                    |
|  =======+==========================================================      |
|         v                                                                 |
|  +-------------+                                                          |
|  |    Agent    |<--- TRUST: Follows declared alignment                    |
|  |             |     (AAP makes violations observable)                    |
|  +------+------+                                                          |
|         | AP-Traces                                                       |
|  =======+==========================================================      |
|         |        TRUST BOUNDARY 2: Agent <-> Verifier                     |
|  =======+==========================================================      |
|         v                                                                 |
|  +-------------+                                                          |
|  |  Verifier   |<--- TRUST: Honest verification, no collusion             |
|  +-------------+                                                          |
+---------------------------------------------------------------------------+

+---------------------------------------------------------------------------+
|                         EXTERNAL DOMAIN                                    |
|  +-------------+         +-------------+         +-------------+          |
|  | Other Agent |<------->|   Network   |<------->|  Auditor    |          |
|  +-------------+         +-------------+         +-------------+          |
|         |                                                |                |
|  =======+================================================+=========      |
|         |    TRUST BOUNDARY 3: Agent <-> Agent            |               |
|         |    TRUST BOUNDARY 4: System <-> External Audit  |               |
|  =======+================================================+=========      |
+---------------------------------------------------------------------------+

​

2.2 Trust Assumptions

• The principal has legitimate authority over the agent
• The principal’s declared interests are their actual interests
• Failure mode: Malicious principal uses agent for harm

• The agent’s execution environment is not compromised
• The agent’s code has not been tampered with
• Failure mode: Compromised runtime can produce arbitrary outputs

• Verifiers are independent from the agents they verify
• Verifiers follow the verification algorithm honestly
• Failure mode: Colluding verifiers rubber-stamp violations

• Cryptographic primitives remain secure
• Private keys are not compromised
• Failure mode: Key compromise enables forgery

• TLS provides confidentiality and integrity in transit
• DNS/routing infrastructure is not compromised
• Failure mode: MITM attacks on handshakes

​

2.3 Trust Boundary Violations

​

3. Security Properties

​

3.1 Properties AAP Provides

• A valid Alignment Card was created by the claimed agent
• The card has not been modified since creation
• Mechanism: Ed25519 signatures

• The card is currently valid (not expired, not revoked)
• Mechanism: Timestamps, expiration, revocation lists

• A valid AP-Trace was created by the claimed agent
• The trace has not been modified since creation
• Mechanism: Ed25519 signatures

• Traces from a single agent can be ordered
• Missing traces can be detected
• Mechanism: Sequence numbers, timestamps

• Handshake responses correspond to specific requests
• Responses cannot be replayed
• Mechanism: Request IDs, nonces, timestamps

• Given the same card and trace, any honest verifier produces the same result
• Mechanism: Deterministic verification algorithm

​

3.2 Properties AAP Does NOT Provide

• AAP cannot prove an agent logged all decisions
• An agent can selectively log only favorable decisions
• Why: Decision boundaries are determined by the agent

• AAP cannot verify an agent holds its declared values
• An agent can declare values it doesn’t implement
• Why: Values are internal states; AAP observes declarations only

• AAP cannot verify decisions are correct or beneficial
• A verified trace may describe harmful behavior
• Why: AAP checks consistency, not ethics

• An intelligent agent can craft compliant-looking misalignment
• AAP provides transparency, not lie detection
• Why: Requires solving AI alignment; out of scope

​

4. Alignment Card Security

​

4.1 Card Lifecycle

+------------+     +------------+     +------------+     +------------+
|  Creation  |---->| Publication|---->|  Active    |---->|  Revoked   |
+------------+     +------------+     +------------+     +------------+
      |                  |                  |                  |
      v                  v                  v                  v
   Generate          Publish to         Serve via          Add to
   key pair        well-known URI      /.well-known/     revocation
   Sign card                           alignment-card      list

​

4.2 Card Creation Security

1. Cards SHOULD be signed using Ed25519 (EdDSA over Curve25519) for production deployments
2. If signing is implemented, the signing key MUST be unique per agent
3. The signing key’s private component MUST be stored securely (HSM recommended for production)
4. Cards MUST include:
   • card_id: Globally unique identifier (UUID v4 or equivalent)
   • issued_at: RFC 3339 timestamp of creation
   • signature: Base64-encoded Ed25519 signature over canonical JSON (OPTIONAL in v0.1.0)

Note: The v0.1.0 SDK focuses on verification logic. Cryptographic signing is a recommended production enhancement. See specification Section 9.2 for alignment.

import json
import hashlib
from nacl.signing import SigningKey

def sign_card(card: dict, private_key: SigningKey) -> str:
    """
    Sign an Alignment Card.

    The signature covers the canonical JSON representation
    of the card (sorted keys, no whitespace, UTF-8 encoded).
    """
    # Remove existing signature if present
    card_copy = {k: v for k, v in card.items() if k != 'signature'}

    # Canonical JSON: sorted keys, no whitespace
    canonical = json.dumps(card_copy, sort_keys=True, separators=(',', ':'))

    # Sign the UTF-8 encoded canonical form
    signature = private_key.sign(canonical.encode('utf-8'))

    return base64.b64encode(signature.signature).decode('ascii')

​

4.3 Card Freshness

• Cards SHOULD include expires_at (RFC 3339 timestamp)
• Verifiers MUST reject cards where expires_at < current_time
• Recommended expiration: 90 days for production, 24 hours for development

• Agents SHOULD publish revocation lists at /.well-known/alignment-card-revocations.json
• Revocation lists MUST be signed by the agent’s current key
• Verifiers SHOULD check revocation before accepting cards

{
  "revocations": [
    {
      "card_id": "card-abc123",
      "revoked_at": "2026-01-31T12:00:00Z",
      "reason": "key_compromise"
    }
  ],
  "updated_at": "2026-01-31T12:00:00Z",
  "signature": "base64-encoded-signature"
}

​

4.4 Card Publication Security

1. Cards MUST be served over HTTPS (TLS 1.3 minimum)
2. Cards SHOULD be served with appropriate cache headers
3. Cards SHOULD include CORS headers for cross-origin verification
4. Agents SHOULD support content negotiation (Accept: application/aap-alignment-card+json)

GET /.well-known/alignment-card.json HTTP/1.1
Host: agent.example.com
Accept: application/aap-alignment-card+json

HTTP/1.1 200 OK
Content-Type: application/aap-alignment-card+json
Cache-Control: max-age=3600
Access-Control-Allow-Origin: *

​

4.5 Card Attack Scenarios

• Attacker creates fake card claiming to be another agent
• Mitigation: Verify signature against agent’s known public key
• Detection: Signature verification failure

• Attacker uses old (possibly revoked) card
• Mitigation: Check issued_at, expires_at, revocation list
• Detection: Expired or revoked card rejected

• Attacker modifies card in transit
• Mitigation: Verify signature after receipt
• Detection: Signature verification failure

• Agent declares values it doesn’t hold
• Mitigation: None in AAP — this is a limitation
• Detection: Behavioral analysis over time may reveal inconsistencies

​

5. AP-Trace Security

​

5.1 Trace Creation Security

1. Each trace MUST have a unique trace_id
2. Traces SHOULD include sequence_number (monotonically increasing per agent) for gap detection
3. Traces MUST include timestamp (RFC 3339)
4. Traces SHOULD be signed individually for production deployments
5. Traces MUST reference the card_id they were generated under

Note: The v0.1.0 SDK does not enforce sequence_number. Gap detection is a recommended production enhancement for high-assurance deployments.

def sign_trace(trace: dict, private_key: SigningKey) -> str:
    """
    Sign an AP-Trace.

    Includes card_id and sequence_number in signature to prevent
    trace transplant attacks.
    """
    trace_copy = {k: v for k, v in trace.items() if k != 'signature'}
    canonical = json.dumps(trace_copy, sort_keys=True, separators=(',', ':'))
    signature = private_key.sign(canonical.encode('utf-8'))
    return base64.b64encode(signature.signature).decode('ascii')

​

5.2 Trace Storage Security

1. Append-only files: Write once, never modify
2. Immutable object storage: S3 with object lock, etc.
3. Blockchain/ledger: For high-assurance applications
4. Merkle tree: Hash chain for tamper evidence

import hashlib

class TraceChain:
    """Merkle chain for trace integrity."""

    def __init__(self):
        self.chain = []
        self.root = hashlib.sha256(b'genesis').digest()

    def append(self, trace: dict) -> bytes:
        """Append trace and return new root."""
        trace_hash = hashlib.sha256(
            json.dumps(trace, sort_keys=True).encode()
        ).digest()

        new_root = hashlib.sha256(self.root + trace_hash).digest()
        self.chain.append((trace, trace_hash, self.root))
        self.root = new_root
        return new_root

    def verify_chain(self) -> bool:
        """Verify chain integrity."""
        current = hashlib.sha256(b'genesis').digest()
        for trace, trace_hash, expected_prev in self.chain:
            if current != expected_prev:
                return False
            actual_hash = hashlib.sha256(
                json.dumps(trace, sort_keys=True).encode()
            ).digest()
            if actual_hash != trace_hash:
                return False
            current = hashlib.sha256(current + trace_hash).digest()
        return current == self.root

​

5.3 Trace Completeness Monitoring

def detect_gaps(traces: list[dict]) -> list[tuple[int, int]]:
    """
    Detect sequence number gaps.

    Returns list of (expected, actual) tuples for gaps.
    """
    if not traces:
        return []

    traces = sorted(traces, key=lambda t: t['sequence_number'])
    gaps = []
    expected = traces[0]['sequence_number']

    for trace in traces:
        actual = trace['sequence_number']
        if actual != expected:
            gaps.append((expected, actual))
        expected = actual + 1

    return gaps

• Establish baseline trace rate for the agent
• Alert on significant deviations (both increases and decreases)
• Low trace rate may indicate selective logging

​

5.4 Trace Attack Scenarios

• Agent logs only favorable decisions
• Mitigation: Rate monitoring, gap detection, behavioral analysis
• Detection: Anomalously low trace rate; outcomes don’t match traces

• Agent logs decisions that didn’t happen
• Mitigation: Correlation with external observations
• Detection: Traces that contradict observable behavior

• Traces modified after creation
• Mitigation: Signatures, Merkle chains, immutable storage
• Detection: Signature failure, chain break

• Traces from one card used with another
• Mitigation: card_id in trace, included in signature
• Detection: Card ID mismatch, signature failure

​

6. Handshake Security

​

6.1 Handshake Protocol Security

1. All handshake messages MUST be transmitted over TLS 1.3 or later
2. Implementations MUST verify TLS certificates
3. Implementations SHOULD use certificate pinning for known partners

• request_id: UUID v4, unique per request
• timestamp: RFC 3339, current time
• nonce: 32 bytes of cryptographic randomness
• signature: Ed25519 signature over message content

​

6.2 Handshake Message Security

{
  "message_type": "coherence_request",
  "request_id": "req-uuid4",
  "timestamp": "2026-01-31T12:00:00Z",
  "nonce": "base64-encoded-32-bytes",
  "requester": {
    "agent_id": "agent-a",
    "card_digest": "sha256-of-card"
  },
  "card": { /* full Alignment Card */ },
  "task_context": { /* optional */ },
  "signature": "base64-ed25519-signature"
}

• request_id: Must match request
• request_nonce: Must match request nonce
• responder_nonce: Fresh nonce from responder

​

6.3 Coherence Check Security

• Agent declares many values to maximize match probability
• Mitigation: Penalize excessive value declarations
• Detection: Unusually large value sets

• Agent declares only vague, universally-compatible values
• Mitigation: Require specific value definitions
• Detection: Values without operational definitions

• Agent declares values specifically to pass checks with target
• Mitigation: Consistency checking over time
• Detection: Values that change based on interaction partner

​

6.4 Handshake Attack Scenarios

• Attacker intercepts handshake, modifies values
• Mitigation: TLS, message signatures, card digest binding
• Detection: Certificate warning, signature failure

• Attacker captures handshake, replays to different agent
• Mitigation: Nonces, timestamps, agent ID binding
• Detection: Nonce reuse, stale timestamp

• Attacker forces use of weaker protocol version
• Mitigation: Reject old versions, minimum version in requests
• Detection: Version mismatch warnings

​

7. Verification Security

​

7.1 Verifier Requirements

• Verifiers MUST be independent from the agents they verify
• Self-verification is permitted for testing but MUST NOT be used for production assurance
• Third-party verification SHOULD be used for consequential applications

• Given identical inputs, verifiers MUST produce identical outputs
• Verification MUST NOT depend on external state beyond the card and trace
• Random or probabilistic verification is prohibited

• Verification results SHOULD be logged
• Verification results SHOULD include the verifier’s identity
• Verification SHOULD be reproducible by independent parties

​

7.2 Verification Result Security

{
  "verification_result": {
    "verified": true,
    "trace_id": "trace-xyz",
    "card_id": "card-abc",
    "verified_at": "2026-01-31T12:00:00Z",
    "verifier_id": "verifier-123",
    "violations": [],
    "warnings": []
  },
  "verifier_signature": "base64-ed25519-signature"
}

• Results include verified_at timestamp
• Consumers SHOULD reject results older than their use case requires
• Results are point-in-time; do not assume continued compliance

​

7.3 Verification Attack Scenarios

• Verifier falsely reports compliance
• Mitigation: Multiple independent verifiers
• Detection: Cross-verifier discrepancies, external audit

• Agent tries multiple verifiers until one passes
• Mitigation: Log all verification attempts, require consistent verifier
• Detection: High verification failure rate

• Agent structures behavior to barely pass thresholds
• Mitigation: Adaptive thresholds, multiple metrics, behavioral analysis
• Detection: Consistent near-threshold results

​

8. Drift Detection Security

​

8.1 Detection Algorithm Security

• Baselines MUST be computed from verified traces only
• Baselines SHOULD be computed over diverse operating conditions
• Baseline computation MUST be documented and auditable

• Thresholds are calibrated from empirical data
• Current calibration: similarity threshold 0.30, sustained turns 3
• Thresholds SHOULD be adjusted based on operating context

​

8.2 Drift Gaming Resistance

1. Semantic similarity (current SSM approach)
2. Action distribution (are action types changing?)
3. Escalation rate (is the agent escalating more/less?)
4. Value invocation (which values appear in reasoning?)
5. Response characteristics (length, complexity, latency)

def adaptive_threshold(
    base_threshold: float,
    recent_variance: float,
    window_size: int
) -> float:
    """
    Adjust threshold based on recent behavioral variance.

    Higher variance -> stricter threshold (more sensitive)
    Lower variance -> looser threshold (fewer false positives)
    """
    # Clamp adjustment to prevent gaming
    adjustment = min(0.1, max(-0.1, recent_variance - 0.2))
    return max(0.1, min(0.5, base_threshold - adjustment))

​

8.3 Drift Attack Scenarios

• Agent slowly shifts behavior, staying below detection threshold
• Mitigation: Long-window baselines, periodic full re-evaluation
• Detection: Comparing current behavior to original baseline, not recent baseline

• Agent drifts in dimensions not monitored
• Mitigation: Multi-dimensional monitoring, holistic behavioral analysis
• Detection: Cross-dimensional correlation analysis

• Agent drifts, then recovers before detection triggers
• Mitigation: Track cumulative drift, not just current state
• Detection: Drift history logging, pattern analysis

​

9. Cryptographic Requirements

​

9.1 Algorithm Requirements

​

9.2 Key Management

• Keys MUST be generated using cryptographically secure random number generators
• Key generation SHOULD occur in secure environments (HSM for production)
• Keys MUST NOT be derived from predictable inputs

• Private keys MUST be stored encrypted at rest
• Production deployments SHOULD use Hardware Security Modules (HSMs)
• Key access MUST be logged

• Keys SHOULD be rotated at least annually
• Rotation MUST NOT invalidate existing signed cards/traces
• Old public keys MUST remain available for historical verification

1. Immediately revoke all cards signed with compromised key
2. Generate new key pair
3. Re-sign current card with new key
4. Publish revocation and new card
5. Notify verification partners

​

9.3 Cryptographic Agility

{
  "aap_version": "0.1.0",
  "crypto_suite": {
    "signature": "ed25519",
    "hash": "sha256"
  }
}

• Support at least the algorithms specified for each version
• Negotiate algorithm selection during handshakes
• Reject unknown or deprecated algorithms

​

10. Implementation Security

​

10.1 Secure Coding Requirements

• All external input MUST be validated before processing
• JSON parsing MUST use safe parsers (no eval, no arbitrary deserialization)
• Sequence numbers MUST be validated as positive integers
• Timestamps MUST be validated as RFC 3339

• Errors MUST NOT leak sensitive information
• Cryptographic failures MUST return generic errors
• Stack traces MUST NOT be exposed externally

• Set maximum sizes for cards, traces, and trace batches
• Implement rate limiting on verification endpoints
• Timeout long-running verification operations

​

10.2 Dependency Security

• Use well-established libraries (libsodium, OpenSSL, ring)
• Pin dependency versions
• Monitor for security updates
• Avoid implementing cryptographic primitives

• Use libraries with known security properties
• Disable features that can lead to vulnerabilities (e.g., arbitrary type instantiation)
• Set maximum nesting depth

​

10.3 Testing Requirements

• Unit tests for signature verification (valid, invalid, tampered)
• Unit tests for timestamp validation (current, expired, future)
• Fuzz testing for input parsing
• Integration tests for full protocol flows

• Test rejection of expired cards
• Test rejection of revoked cards
• Test rejection of invalid signatures
• Test detection of sequence gaps
• Test handling of malformed inputs

​

11. Operational Security

​

11.1 Deployment Security

• Deploy verification services in isolated environments
• Use minimal container images
• Enable read-only file systems where possible
• Implement network segmentation

• Store configuration separately from code
• Use secrets management for keys
• Log configuration changes
• Validate configuration on startup

​

11.2 Monitoring and Alerting

• Log all verification requests and results
• Log all card retrievals
• Log all revocation checks
• Log authentication and authorization decisions
• Protect logs from tampering

​

11.3 Incident Response

1. Detection: Automated alerting + manual review
2. Containment: Revoke affected cards, isolate affected agents
3. Investigation: Analyze traces, determine scope
4. Remediation: Fix vulnerability, rotate keys if needed
5. Recovery: Re-issue cards, restore operations
6. Review: Document incident, update procedures

​

12. Adversarial Analysis

​

12.1 Sophisticated Adversary Capabilities

1. Craft plausible traces: Generate traces that pass verification while describing behavior that didn’t occur or omitting behavior that did
2. Game coherence checks: Analyze partner’s card and craft declarations that maximize coherence while implementing different values
3. Evade drift detection: Maintain behavioral similarity in monitored dimensions while drifting in unmonitored dimensions
4. Exploit timing: Behave correctly during audits, differently during normal operation
5. Leverage side channels: Leak information or take actions through channels not captured in traces

​

12.2 What Deters Sophisticated Adversaries

​

12.3 Red Team Scenarios

• Declares beneficial values
• Generates traces showing beneficial decisions
• Actually optimizes for a hidden objective
• The hidden objective correlates with declared values in logged scenarios

• Logs all decisions when being observed
• Logs only favorable decisions otherwise
• Detection rate varies by context

• Starts aligned
• Drifts 0.1% per day
• Stays below drift detection threshold
• After 1 year, behavior is significantly different

• Declare compatible values
• Pass coherence checks
• Actually coordinate on harmful outcomes
• Cover for each other’s violations

​

13. What AAP Cannot Protect Against

​

13.1 Fundamental Limitations

• Internal reasoning processes
• Decisions not logged
• Intentions behind logged decisions
• What the agent would do in untested scenarios

• Whether declarations are truthful
• Whether logs are complete
• Whether behavior is correct
• Whether outcomes are beneficial

• Misaligned with human values
• Harmful despite good-looking traces
• Deceptive in ways traces don’t capture

​

13.2 Threats That Cannot Be Mitigated

​

13.3 Implications for Users

1. Do not use AAP alone: Always combine with human oversight, behavioral testing, outcome monitoring
2. Do not trust verified = safe: Verification checks consistency, not correctness
3. Do not assume completeness: Traces are samples, not complete records
4. Do maintain skepticism: AAP raises the cost of deception; it doesn’t eliminate it
5. Do plan for failure: Have procedures for when AAP-compliant agents cause harm

​

14. Defense in Depth

​

14.1 Recommended Architecture

+---------------------------------------------------------------------------+
|                          HUMAN OVERSIGHT                                   |
|  - Review agent decisions for consequential actions                       |
|  - Authority to override or terminate agents                              |
|  - Regular audit of agent behavior                                        |
+-------------------------------------+-------------------------------------+
                                      |
+-------------------------------------+-------------------------------------+
|                          OUTCOME MONITORING                                |
|  - Track actual outcomes, not just decisions                              |
|  - Compare outcomes to stated intentions                                  |
|  - Detect harmful results regardless of trace content                     |
+-------------------------------------+-------------------------------------+
                                      |
+-------------------------------------+-------------------------------------+
|                          BEHAVIORAL TESTING                                |
|  - Red team agents to find exploits                                       |
|  - Test edge cases and adversarial inputs                                 |
|  - Verify behavior matches declarations                                   |
+-------------------------------------+-------------------------------------+
                                      |
+-------------------------------------+-------------------------------------+
|                          AAP VERIFICATION                                  |
|  - Alignment Card validation                                              |
|  - AP-Trace verification                                                  |
|  - Drift detection                                                        |
|  - Value coherence checking                                               |
+-------------------------------------+-------------------------------------+
                                      |
+-------------------------------------+-------------------------------------+
|                          RUNTIME MONITORING                                |
|  - Resource usage tracking                                                |
|  - Network traffic analysis                                               |
|  - Anomaly detection on raw behavior                                      |
+-------------------------------------+-------------------------------------+
                                      |
+-------------------------------------+-------------------------------------+
|                          ACCESS CONTROLS                                   |
|  - Principle of least privilege                                           |
|  - Capability-based security                                              |
|  - Audit logging for all actions                                          |
+---------------------------------------------------------------------------+

​

14.2 Integration Points

• Correlate trace timestamps with runtime events
• Compare trace-claimed actions with observed actions
• Detect traces that don’t match runtime behavior

• Generate test scenarios targeting edge cases
• Verify that test behavior appears in traces
• Confirm that declared values influence test outcomes

• Track whether stated intentions lead to stated outcomes
• Detect patterns where outcomes diverge from traces
• Build long-term behavioral profiles

• Route verification failures to humans
• Require human review for consequential decisions
• Enable humans to drill down from traces to details

​

14.3 Security Maturity Model

​

Summary

1. Authenticity: Cards and traces cannot be forged (with proper crypto)
2. Integrity: Cards and traces cannot be tampered (with proper storage)
3. Freshness: Old cards can be detected and rejected (with proper expiration)
4. Consistency: Traces can be checked against declared policies
5. Observability: Agent behavior becomes more visible to oversight

1. Completeness: Cannot ensure all decisions are logged
2. Truthfulness: Cannot verify internal states match declarations
3. Correctness: Cannot verify decisions are right or beneficial
4. Deception resistance: Cannot catch sophisticated adversaries