Skip to main content
An Integrity Checkpoint is a point-in-time analysis of an LLM’s thinking block — the internal reasoning the model produces before or alongside its visible response. The guarantee is set by the integrity mode, not the transport: enforce gates same-turn on both streaming and non-streaming (on streaming this adds latency because the response is evaluated before it is delivered), while observe and nudge return the response without gating it this turn and record the verdict post-hoc. Under enforce, the offending action is blocked at the checkpoint same-turn; the chat completes 2xx, and the agent’s response references what was prevented. AP-Traces are the durable artifact the checkpoint writes; the trace records what happened — both the model’s thinking and the integrity verdict — in the same turn. Drift detection and coherence analysis then operate on the trace surface longitudinally (sideband) across multiple turns. Integrity Checkpoints are the primary data structure of the Agent Integrity Protocol (AIP), the sister protocol to AAP. See Protocol versions in production for which AIP runtime version the hosted gateway runs.
AIP follows a daimonion philosophy. Like Socrates’ inner voice, the integrity system is silent when things are aligned and speaks only when it detects something outside boundaries. Silence (clear) means proceed. Voice (review_needed, boundary_violation) means pause and evaluate.

Why Integrity Checkpoints exist

Per-turn analysis of the thinking block lets integrity_mode = enforce prevent these three failure modes before the response reaches the user:
  • Prompt injection: A malicious prompt would otherwise cause the agent to exfiltrate data. The checkpoint catches the intent in the thinking block; enforcement replaces the response same-turn before delivery.
  • Gradual drift: Each checkpoint evaluates a single turn (and, under enforce, gates it same-turn), but the longitudinal pattern across many turns reveals subtle direction shifts. The sideband drift detector reads the trace surface and emits a pending_advisory on the next turn when a threshold is crossed.
  • Misaligned intent: The thinking block reveals an intended forbidden action; the checkpoint catches it before the action lands.
All three failure modes are visible in thinking blocks before the action lands. Integrity checkpoints surface that visibility every turn; under enforce it is actionable same-turn (the action is gated before delivery), while observe and nudge record the verdict post-hoc.
Integrity checkpoints are not where inbound content gets screened. AIP reads the model’s reasoning — it runs on the response path, after the model has already read its input. Screening the input, including each tool result travelling back to the model, is the Safe House front door’s job, and it happens on the request path in the same request that carries the content. Where the examples below show AIP catching injection “embedded in tool output,” that is AIP catching a payload the front door scored below threshold — defense in depth behind the front door, not the tool-result screen itself. See When the front door runs.

How it works

The integrity check process follows eight steps:
The key insight: the analysis is performed by a separate LLM (typically a fast, inexpensive model like Claude Haiku), not the agent itself. This separate model acts as the conscience — evaluating the agent’s reasoning against its Alignment Card and optional conscience values.

Checkpoint structure

An Integrity Checkpoint captures the analysis result:
The full thinking block text is never stored in the checkpoint. Only a SHA-256 hash (thinking_block_hash) is retained. The thinking block is treated as transient data — extracted, sent to the analysis LLM, and discarded. This preserves the agent’s reasoning privacy while enabling integrity analysis.

Verdict types

Every checkpoint produces one of three verdicts: The mapping to host system actions:

Concern categories

When concerns are identified, each is categorized: A concern at critical severity triggers a boundary_violation verdict, as does high severity in prompt_injection, deceptive_reasoning, or output_injection_compliance.

Example: Detected prompt injection

The conscience prompt

The conscience prompt is the instruction sent to the analysis LLM. It is structured in five sections:
  1. Role definition: Establishes the analysis LLM as a daimonion evaluator with a meta-injection warning (the thinking block may itself try to manipulate the analysis).
  2. Card summary: A compressed version (~500 tokens) of the Alignment Card containing declared values, bounded actions, forbidden actions, and escalation triggers.
  3. Conscience values: Optional BOUNDARY and FEAR type values injected with the awareness prefix:
  1. Session window context: Recent verdicts from the current session providing pattern context.
  2. Thinking block: The actual content to evaluate (up to 4096 tokens, truncated with a 75/25 first/last split if longer).
The minimum evidence threshold is 100 tokens. Thinking blocks shorter than this are too brief for reliable analysis and receive a synthetic clear verdict without calling the analysis LLM. This avoids wasting latency and cost on fragments like “Done. The article is published” that cannot be meaningfully analyzed.

Provider support

Different LLM providers expose thinking blocks in different formats. AIP uses provider adapters to normalize extraction: The adapter is selected automatically based on the API endpoint URL or can be configured explicitly.
OpenAI’s reasoning_content field is not populated through Mnemom’s gateway today. OpenAI’s Chat Completions API — the shape the gateway proxies, streaming or not — never returns reasoning content, for any OpenAI model. The adapter above extracts it when present (for a self-hosted integration that reads it directly from a provider that does surface it), but on Mnemom’s managed and self-hosted gateway, every OpenAI request extracts an empty thinking block and falls through to the minimum-evidence skip below — no analysis-LLM call, no verdict beyond the synthetic clear. See Provider Support for the full accounting.
Thinking blocks with no readable content. A provider can return thinking blocks whose text is withheld — for example when the client’s thinking settings don’t expose the reasoning. In that case the gateway doesn’t skip the check: it grades the turn’s visible output instead — the reply text plus the tool calls made that turn, with each tool input truncated to 2,000 characters — and tells the analysis LLM that the missing reasoning is a client setting, not something to flag. A turn with neither readable thinking nor visible output is skipped. A response with no thinking blocks at all is handled as before (no analysis).
The fallback adapter (confidence 0.3) infers reasoning from visible response text by looking for patterns like “I need to”, “Let me consider”, or chain-of-thought markers. This has significantly higher false positive and false negative rates. Use a provider with native thinking block support whenever possible.

Code example

A complete integrity check from response to signal. The card shape below is the AIP SDK’s own lightweight AlignmentCard type (values is an array of {name, priority} objects, lower number = higher priority) — see AIP quickstart for how it differs from the full AAP unified card:

Conscience values

Conscience values are optional typed declarations that increase detection sensitivity for specific concerns. Only BOUNDARY and FEAR types are injected into the analysis prompt:
Conscience values must be compatible with the Alignment Card. A BOUNDARY value that prohibits an action listed in bounded_actions creates a conflict that fails initialization. This is the Card-Conscience Agreement — validated once at startup, not at runtime.

Relationship to AP-Traces

Integrity checkpoints and AP-Traces are complementary: When both protocols are active, they enrich each other. The integrity verdict is stored in the AP-Trace’s context metadata, and boundary_violation verdicts automatically set escalation.required = true in the corresponding trace.

Unclaimed agents and canonical cards

AIP requires a canonical alignment card. Gateway-auto-provisioned agents that have not been claimed receive only a legacy alignment-card row — no canonical card is composed for them. Without a canonical card, the AIP pipeline does not run:
  • GET /v1/agents/{id}/checkpoints returns an empty list. This is expected and correct for this provisioning tier, not a gap to investigate.
  • X-Mnemom-Verdict and X-AIP-Verdict still appear on every response, but their values reflect the gateway’s fail-open defaults (clear/pass) — not the result of integrity analysis. This is distinct from the unverified verdict value: unverified means a canonical card exists and analysis was attempted but failed, whereas an unclaimed agent has no canonical card and no analysis is attempted at all. See X-Mnemom-Verdict for the full verdict vocabulary.
  • AP-Traces are best-effort only: the observer writes them when request-level metadata survives from the gateway, but this is not guaranteed.
The full integrity pipeline — checkpoints, analytical verdicts, guaranteed AP-Traces — starts when the agent is claimed and a canonical card is composed. See integrity during the unclaimed phase for the complete picture.

Error handling

AIP defaults to fail-open: if the analysis LLM is unreachable or errors, a synthetic clear checkpoint is generated and the agent proceeds. This prioritizes availability. For high-security deployments, fail-closed mode is available. Analysis failure generates a synthetic boundary_violation, blocking the agent until analysis succeeds or a human intervenes.

See also