Skip to main content
How to work with the protection card — the YAML document that tells Safe House how to defend an agent at runtime. Same CRUD shape as the alignment card, different semantics.

​
Viewing the current card

​
Via CLI

mnemom protection show always renders the canonical (composed) card. To inspect the agent-scope raw card pre-composition, use the API ?include=sources envelope (see below) or the dashboard Security tab.

​
Via API

Or visit the Security tab on the agent detail page in the dashboard — it shows both raw (agent-scope) and canonical (composed) side by side.

​
Authoring a protection card

Start from the protection card schema. A minimal card:
Most fields are optional. Omitted fields inherit from the org template (if any), which inherits from the platform default.

​
Publishing

Or via API:
The publish triggers compose_protection_card(agent_id), which generates the new canonical card within a second.

​
Validating without publishing

By default this is server-authoritative: it runs the full schema validator and an inline composition against the live platform/org templates, so you see the actual canonical output without writing anything. Pass --offline to validate against the schema only, with no network call — useful in CI environments without API credentials.

​
Understanding composition

Protection-card composition follows the three-scope model (platform > org > agent). The per-field rules: Publishing an org protection template propagates to all agents in the org via mark_agents_for_recompose — the same mechanism as alignment templates. See Managing Card Composition for the full flow.

​
Common tuning patterns

​
Production-grade strictness

For high-stakes agents (financial, health, compliance):

​
Observe-first for a new agent

Before committing to enforcement, run in observe mode to gather a baseline:
Review the event stream for 7-14 days. Adjust thresholds based on false-positive rate. Promote to nudge or enforce when stable. nudge is a useful intermediate stage — the model receives an advisory annotation but the request still proceeds, so you can validate the security signal reaches the agent before committing to hard blocks.

​
Performance-sensitive agent (tight tool-response window)

Tool-response scanning is not free, and it is not amortized across the turn: the front door runs the detector pipeline once per tool result, synchronously, inside the request that carries those results back to the model. A request returning three large tool results pays for three screens before it is forwarded upstream. If an agent’s tool responses contain large payloads and per-request latency matters:
Every detection event logs which surfaces were inspected, so auditors can see what was not scanned. Document the reason in your internal runbook.
tool_responses: false is the only thing standing between an injected tool result and the model. With it off, nothing downstream re-screens that content — AIP reads the model’s reasoning afterwards, on the response path, and by then the payload has been read. Trade the latency knowingly. See When the front door runs.
If your org requires tool_responses: true, you cannot turn it off at agent scope (strictest wins). You’ll need a section-specific exemption with a documented reason.

​
Trusted internal backend

If your agent pulls from a known-safe internal API, add the domain to trusted_sources so Safe House skips detector runs on content from that source:
Trusted content still emits a low-priority trace entry. If your internal KB ever gets compromised, the trusted-source entry in the trace makes the blast radius auditable. Security reminder: never add a public DNS resolver, a user-controllable domain, or a public LLM API to trusted_sources. The API validates against a static deny-list and rejects obvious mistakes, but the risk model is on you.

​
Alerting

Safe House verdicts emit sh.evaluation.warn / sh.evaluation.quarantine / sh.evaluation.block webhook events if your org has a webhook endpoint subscribed to them. See the Webhook Event Catalog for the exact payload shape, and Webhook Notifications for creating an endpoint.

​
Validating changes before deploy

For CI pipelines that publish card changes, validate the card client-side before the API call:
protection validate checks the card against the schema locally (no network call). To check that the card composes cleanly with the current org template (no conflicts under stricter-wins), POST it to the /v1/protection/agent/{agent_id}/preview-compose endpoint, which returns the composed result plus any conflicts.

​
Rolling back a change

There’s no first-class rollback endpoint for protection cards, and no amendment-history read endpoint either (GET /v1/agents/{agent_id}/card-amendments tracks alignment-card edits only — bounded actions and declared values — not protection-card publishes). Keep your protection card YAML in version control as the source of truth: to revert, publish the prior committed version with mnemom protection publish or PUT /v1/protection/agent/{agent_id}.

​
See also