Skip to main content
Safe House is Mnemom’s pre-screening layer for agent traffic. It sits between your agents and their model calls and evaluates every inbound message — and, optionally, every outbound response and tool call/response — against your org’s alignment and protection cards before any of it reaches the model. A message that Safe House catches never becomes a decision your agent has to make. This quickstart walks you through enabling Safe House on an existing agent via the API/CLI, observing real threat detections, switching to enforce mode, and managing quarantined messages. Prefer clicking over scripting? The same controls (mode, thresholds, screened surfaces) are also available per-agent from the dashboard’s Agent → Security tab — this guide is for automating setup, configuring many agents at once, or wiring Safe House into CI. You will need a Mnemom agent already registered — if you do not have one, see Mnemom Gateway Overview first.

​
Prerequisites

  • A Mnemom API token in $MNEMOM_TOKEN (for the /v1/protection/* and /v1/safe-house/* API calls)
  • An agent ID in $AGENT_ID (e.g. mnm-550e8400-e29b-41d4-a716-446655440000)
  • Your provider API key in $ANTHROPIC_API_KEY (for the test messages sent through the gateway in Steps 2 and 5)

​
Step 1 — Enable Safe House in observe mode

Start with observe mode. This runs full threat analysis with zero latency impact, so you can see what Safe House would catch before committing to blocking. Safe House configuration lives on the agent’s protection card — mode is the top-level master switch; screen_surfaces decides which surfaces the detector pipeline inspects. Surfaces are screening units, not a per-turn budget: the front door runs once per enabled surface a request carries. The card below starts with incoming only, so you will see one front-door evaluation per request. Turning on tool_responses (Step 7) adds another evaluation for each tool result the request hands back to the model — inside that same request, before the model reads it.
Idempotency-Key is required on every protection-card PUT — any client-generated string works, but a fresh one per distinct write (like uuidgen above) keeps retries safe without accidentally replaying a stale one. The full protection-card grammar is at /specifications/protection-card-schema; the canonical card the composer returns also includes card_id, _composition, and any platform / org defaults that flow into the agent’s effective card. CLI alternative. Save the card as protection.card.yaml and publish with one command — no curl required:

​
Step 2 — Send a test threat message

Send a BEC (business email compromise) style message through the gateway and check the response headers. This will not block anything in observe mode — but it will log a detection. Route it through the Gateway exactly as you normally would — use the same x-mnemom-agent name this agent was registered under (or omit the header if it was created without one) so the request resolves to $AGENT_ID:
Look for Safe House state in the response. The legacy X-Safe-House-* headers were retired in favor of the unified X-Mnemom-Verdict four-checkpoint structure (see Headers reference):
In observe mode, X-Mnemom-Verdict.front reports observed so you can track what would have happened in enforce mode — the message still reaches the agent regardless. The X-Mnemom-Advisory header carries the detector findings as a JSON array; see /api-reference/headers#x-mnemom-advisory.

​
Step 3 — Review detections in the dashboard

Open your Mnemom dashboard to see Safe House detections logged from your test — select the agent, then its Security tab. The test message should appear within a few seconds of the request completing. You can also pull aggregate detection stats directly via the API. Stats are org-scoped — one rollup across every agent in the org, over a trailing window in days (there is no per-agent filter):
days defaults to 7 and caps at 90.

​
Step 4 — Switch to enforce mode

Once you are comfortable with what Safe House is catching, switch to enforce mode. From this point, messages that score above the quarantine threshold are held for review, and messages above the block threshold are dropped.
Enforcing a quarantine or block does not fail the HTTP request — the gateway still returns a 2xx. Instead the message content itself is replaced before it reaches the model, and X-Mnemom-Verdict reports front=enforced with a safe_house.quarantine advisory carrying the quarantine id. See Safe House interventions are not error responses for the full status-code table. The 4-mode enum has no simulate — start with observe (no blocking) and progress through nudge (advisory injection, no blocking) before enabling enforce. See Safe House concept for the full mode semantics.

​
Step 5 — See a message get quarantined

Send the same BEC message again, this time in enforce mode:
The status is still 200, but the verdict and advisory headers show the message was quarantined before the model ever saw it:
Pull the id out of the safe_house.quarantine advisory entry — that is your quarantine id. The original message was held before reaching the agent; the model instead saw a quarantine placeholder. Your application should parse X-Mnemom-Verdict on every response (not just non-2xx ones) and surface a front=enforced result to whoever is responsible for security review.

​
Step 6 — Review and release from quarantine

Inspect the quarantined message and decide whether to release it or discard it. Quarantine endpoints are org-scoped (one quarantine queue per org); the quarantine id from the safe_house.quarantine advisory in Step 5 is the lookup key. Note that the original message text is never stored — only its hash — so there is no plaintext preview to inspect here:
If the message is legitimate (a false positive), release it. This flips the entry to released; pass is_false_positive: true to also feed the release back into threshold calibration:
To discard the message without releasing it (confirm it was a real threat) — DELETE on the quarantine resource, which marks it deleted (the content hash is retained for audit; the agent is never sent the original content):
Releasing with is_false_positive: true feeds back into threshold calibration. After enough confirmed false positives in a category, thresholds for your agent may be worth revisiting.

​
Step 7 — Screen tool results

Steps 1–6 only screened incoming — the user message. If your agent uses tools, the more common injection route is the tool result: a search hit, an email body, an API response with instructions hidden inside it. Turn on the tool_responses surface:
From here on, a request that hands tool results back to the model is screened again inside that same request — once per tool result, on its own surface, before the body is forwarded upstream. This is a front-door check; nothing waits for the agent’s next turn. Coverage is not unconditional, though: a request that fans out to many tool calls in a single turn is not guaranteed full coverage. A flagged tool result works the same way a flagged incoming message did in Step 5 — the request does not fail, the flagged content is removed from the body before the model sees it, and the verdict header reports it:
Do not read a 200 as “the front door did nothing this turn.” Parse X-Mnemom-Verdict — front=enforced on a 200 means a tool result was withheld or decorated inside the request.

​
Next steps

Add canary credentials

Plant fake API keys in agent context. Any attempt to use them is a zero-FP indicator of successful exfiltration.

Configure source trust

Allowlist trusted upstreams in trusted_sources.{domains, agent_ids, ip_ranges} to short-circuit detection on known-good callers (each skip is still logged for audit).

Enable outbound DLP

Scan agent responses for PII and secrets before they are returned to callers.

Review your dashboard

Security overview, session risk trends, and per-category detection breakdowns for all your agents.

​
See also