Security & Trust Model

This document describes the unified security and trust model across the full Mnemom stack: the Agent Alignment Protocol (AAP), the Agent Integrity Protocol (AIP), and Mnemom Gateway — the gateway that ties them together. It covers what data is stored, how authentication works, how data is encrypted, and what threats the system does and does not defend against.

---

​

Trust model overview

Mnemom provides transparency, not guarantees. The two protocols serve complementary roles:

• AAP provides post-hoc verification. It records agent decisions as AP-Traces, detects behavioral drift, and verifies traces against declared Alignment Cards. AAP operates after the action has been taken — typically 30-60 seconds later.
• AIP provides per-turn detection. It analyzes the agent’s thinking blocks, producing integrity verdicts. In enforce, the verdict gates the current turn — the response is evaluated before it is delivered (which adds latency); in observe and nudge it is recorded post-hoc, available before the next action executes.

Together they provide full-coverage observability: AIP catches problems as the agent thinks; AAP catches problems after the agent acts. The cross-protocol linkage (IntegrityCheckpoint.linked_trace_id references APTrace.trace_id) creates a complete audit chain from reasoning to decision. Mnemom Gateway is the operational layer that runs both protocols. It is a Cloudflare Workers gateway that intercepts LLM API traffic, extracts thinking blocks for AIP analysis, generates AP-Traces for AAP verification, and enforces configurable enforcement modes based on the combined results.

---

​

Data handling

​

What is stored

​

What is NOT stored

---

​

Authentication & authorization

The Mnemom API supports three end-caller authentication patterns, plus an internal service role. Each serves a different use case; the API’s auth layer dual-resolves them into the same downstream principal.

​

Session cookie (mnemom_session)

Used for authenticated browser sessions — the Mnemom dashboard at mnemom.ai/dashboard (and www.mnemom.ai/dashboard), and any future first-party SPA. The cookie value is an AES-256-GCM-encrypted blob of {access_token, refresh_token, issued_at, auth_method}. The first byte is a key ID enabling zero-downtime key rotation. Tokens are never exposed to JavaScript (HttpOnly) and are transparently refreshed + rotated server-side when the access token nears expiry. MFA step-up is carried through a short-lived mnemom_mfa_pending cookie between POST /v1/auth/sign-in and POST /v1/auth/mfa/verify; the aal1 access token never reaches JS. SSO uses a single-use mnemom_sso_initiator cookie bound to an HMAC-signed state token.

​

Bearer token (Authorization header)

Used by the Mnemom CLI and programmatic agents mimicking its flow. The JWT is issued by Supabase Auth on the user’s behalf and contains identity, organization membership, and role. The CLI obtains its token via a one-time browser → localhost handoff at login time (mediated by POST /v1/auth/cli-exchange, which itself requires a valid session cookie). Tokens are verified on every request via JWKS.

​

API key (X-Mnemom-Api-Key header)

Used for server-to-server and enterprise fleet management — billing API calls, automated agent registration, CI/CD integrations. API keys are scoped to a user or organization. The key itself is never stored; only its SHA-256 hash is persisted for lookup and validation. Keys are issued via the dashboard under Settings > API Keys and can be rotated at any time.

​

Service role key

Used for internal and administrative operations — database migrations, system maintenance, admin export endpoints. Service role access bypasses row-level security.

​

Organization RBAC

Resources are scoped to organizations. Each organization member holds one of three roles: Role-based access is enforced at the API layer via Supabase row-level security policies. Organization-scoped API keys inherit the permissions of the role they were created under.

---

​

Encryption

​

In transit

All endpoints enforce TLS 1.2+. This applies to:

• The Mnemom gateway (Cloudflare Workers edge network)
• The Mnemom API (Cloudflare Workers, api.mnemom.ai)
• Webhook signal delivery (AIP POST to registered endpoints, authenticated with HMAC-SHA256)
• Cross-protocol communication between AAP and AIP components

Cloudflare’s edge network terminates TLS and re-encrypts traffic to origin servers. Certificate management is handled automatically.

​

At rest

Database storage uses Supabase Postgres with encryption at rest. This covers all persisted data: AP-Traces, Integrity Checkpoints, Alignment Cards, drift alerts, enforcement records, and user/organization data.

​

Thinking block privacy

Thinking blocks receive special treatment. The full thinking block content is never written to any persistent storage — not in the database, not in logs, not in object storage. The analysis flow is:

1. The thinking block is extracted from the LLM response (in the gateway or SDK)
2. The thinking block is sent to the analysis LLM for evaluation
3. The analysis result is captured as an Integrity Checkpoint
4. The thinking block content is discarded
5. Only the SHA-256 hash is retained in the checkpoint

---

​

Threat model

The Mnemom stack is designed with explicit awareness of what it can and cannot defend against. The following threat categories are addressed.

​

Out of scope — what Mnemom does NOT defend against

State these upfront so customers under enterprise security review can answer them without reading the whole page.

• Agent trustworthiness. Mnemom makes agent behavior observable; it does not make it trustworthy. A clear integrity verdict is not a safety certificate.
• Honest thinking blocks. AIP analyzes what the model emits as its thinking. A sufficiently sophisticated model can reason silently in one channel and produce sanitized thinking content in another. AIP detects inconsistency between thinking and action; it cannot detect silent deception that never surfaces in the thinking channel at all.
• Model inference correctness. The zero-knowledge proof layer proves that the deterministic verdict-derivation rules were applied honestly to the model’s output. It does not prove the model inference itself was run correctly. Proving model inference at current scale is prohibitively expensive; see the whitepaper for the rationale.
• Upstream prompt injection. AIP detects injection patterns in thinking blocks after the agent has processed injected content. It does not prevent untrusted content from reaching the model. Safe House reduces exposure on inbound and outbound channels (see Safe House threat model), but the broader prompt-injection attack surface — including novel injections the L1 patterns do not match — remains open.
• Model-provider compromise. Mnemom trusts the LLM provider’s API responses. A compromised or malicious provider (returning fabricated thinking blocks, omitting content, or replaying cached responses) is not detected by AIP or AAP.
• Out-of-band agent behavior. If the agent operator disables the Mnemom gateway and calls the LLM provider directly, none of the trust-plane signals apply. AP-Traces, integrity checkpoints, and reputation scoring all require traffic to flow through the gateway (or an SDK-Direct equivalent path).
• Supply-chain and infrastructure attacks on the LLM providers, Mnemom’s hosting (Cloudflare, Supabase, Modal), or the package registries that distribute the Mnemom SDKs. These are mitigated by provider-side controls and Mnemom’s own supply-chain trust practices, not by the protocols themselves.
• Physical-layer tampering with on-chain Merkle anchors on Base L2. The on-chain layer inherits Base/Ethereum’s security assumptions; Mnemom does not defend against 51% attacks, censorship, or chain reorgs beyond L2 finality depth.
• Replacement for human oversight. Mnemom is a transparency and integrity layer, not an autonomous enforcement system. High-stakes decisions — financial transactions above material thresholds, irreversible real-world actions, safety-critical operations — require human-in-the-loop controls set via policy escalation triggers, not full reliance on automated verdicts.

Every item below describes a threat Mnemom does address — treat the list above as the explicit boundary of those claims.

​

Adversarial agents

An agent can produce perfect AP-Traces and pass every integrity checkpoint while acting against its principal’s interests. If the agent controls what it logs and reasons in ways not captured by the thinking block, the protocols provide visibility into what the agent declares and exposes, not what it actually does. AAP provides visibility, not prevention. AIP provides detection, not certainty. Together they raise the cost of deception — an adversarial agent must maintain consistency across both per-turn thinking analysis and post-hoc trace verification — but they do not make deception impossible.

​

Prompt injection

AIP detects injection patterns in thinking blocks. When an agent’s reasoning reveals it is responding to injected instructions (e.g., instructions embedded in tool output rather than the user’s original request), the analysis LLM flags the concern and the checkpoint verdict reflects it. However, AIP operates after the agent has already processed the injected content. The injection has occurred. AIP detects its effects on reasoning and can intervene before the action lands (in gateway or enforce mode), but it does not prevent the injected content from reaching the model in the first place.

​

Replay attacks

Trace IDs (trace_id) and timestamps prevent AP-Trace replay. Each trace is uniquely identified and temporally bound. Integrity Checkpoint IDs (checkpoint_id, format ic-{uuid}) are unique per checkpoint. AIP webhook signals include timestamps, and receivers should reject signals older than a configurable threshold (recommended: 5 minutes). HMAC-SHA256 signatures on webhooks prevent signal forgery.

​

LLM-as-Judge limits

AIP uses an LLM to evaluate another LLM’s thinking. This introduces a fundamental ceiling: the analysis model can be fooled by sophisticated adversarial content crafted specifically to manipulate the evaluation. This is the meta-injection threat — the content under analysis attempts to subvert the analysis itself. Mitigations include structured output validation, explicit meta-injection warnings in the conscience prompt, and using a separate model instance (ideally a different model family) for analysis. These raise the bar but do not eliminate the risk.

​

Model dependency

AIP requires models that expose thinking blocks. Current provider support: Models without exposed thinking blocks cannot be analyzed by AIP. In this case, the system generates synthetic clear verdicts — the agent proceeds, but without integrity analysis. This is a known gap: models with opaque reasoning are invisible to AIP.

---

​

Retention & audit

​

Configurable retention

Trace and checkpoint retention is configurable via the audit.retention_days field in the Alignment Card. This field declares how long the agent’s operator commits to retaining audit data.

​

Queryability

AP-Traces and Integrity Checkpoints are queryable via the Mnemom API:

• GET /agents/{agent_id}/traces — Retrieve traces for an agent
• GET /traces/{trace_id} — Retrieve a specific trace
• GET /agents/{agent_id}/checkpoints — Retrieve integrity checkpoints for an agent
• GET /agents/{agent_id}/checkpoints/{checkpoint_id} — Retrieve a specific checkpoint
• GET /drift/{agent_id} — Retrieve drift analysis for an agent

​

Compliance exports

Enterprise customers have access to compliance export endpoints for bulk data retrieval:

• GET /billing/export/usage — Export usage data for billing and compliance reporting

Admin export endpoints are available for organization-level data extraction, supporting regulatory audit requirements.

---

​

Cryptographic guarantees

Beyond TLS encryption and HMAC authentication, the AIP attestation layer provides four independent layers of cryptographic evidence. Each layer addresses a distinct verification question.

​

Four layers of verification

Each layer is independently verifiable. A verifier can check any combination of layers depending on their trust requirements.

​

Trust assumptions

The attestation system requires two trust assumptions:

1. Trust the signing key. If the Ed25519 private key is compromised, an attacker can forge signatures on arbitrary checkpoints. Signing keys are managed in Cloudflare Workers secrets and are never exposed to client code. Key rotation is supported via the key_id field in certificates.
2. Trust the analysis model. The ZK proof demonstrates that the verdict was correctly derived from the analysis LLM’s output, but it does not prove the analysis output itself was correct. If the analysis LLM produces incorrect concerns (false positives or false negatives), the verdict will be derived correctly from incorrect inputs. Analysis quality remains bounded by the analysis model’s capability.

​

Public verifiability

All verification endpoints are public and unauthenticated. Anyone can:

• Fetch signing public keys via GET /v1/keys
• Retrieve a certificate via GET /v1/checkpoints/{id}/certificate
• Verify a certificate via POST /v1/verify
• Check a Merkle root via GET /v1/agents/{id}/merkle-root
• Generate an inclusion proof via GET /v1/checkpoints/{id}/inclusion-proof

This means any third party — auditors, regulators, downstream consumers of an agent’s output — can independently verify the integrity of an agent’s analysis history without trusting Mnemom. The certificates are self-describing documents that contain all the information needed for offline verification (once the public key is obtained). For full details on the certificate format and verification steps, see Integrity Certificates. For the ZK proof system, see Verifiable Verdicts.

---

​

Responsible disclosure

If you discover a security vulnerability in any Mnemom component, please report it responsibly via GitHub Security Advisories on the relevant repository:

---

​

See also

• AAP Security Model — Detailed threat analysis, cryptographic requirements, and adversarial scenarios for AAP
• AIP Security Model — Threat model and attack surface analysis for AIP
• AAP Limitations — What AAP cannot protect against
• AIP Limitations — What AIP cannot protect against
• EU AI Act Compliance — Article 50 transparency obligation mapping
• Enforcement Modes — How the gateway acts on protocol verdicts