sh_configs JSON blob, start with the migration guide; the automatic UC-3 migration already composed your old configs into protection cards.
Viewing the current card
Via CLI
Via API
Authoring a protection card
Start from the protection card schema. A minimal card:Publishing
compose_protection_card(agent_id), which generates the new canonical card within a second.
Validating without publishing
Understanding composition
Protection-card composition follows the three-scope model (platform > org > agent). The per-field rules:| Field | Composition |
|---|---|
mode | Strictest wins (enforce > nudge > observe > off). Agent can go stricter, not looser. |
thresholds.* | Min across scopes — lowest = strictest wins. An agent can tighten further than the platform/org but not loosen. |
screen_surfaces.* | OR per field — true wins. Any scope can require scanning a surface; agents cannot turn off scanning the org or platform requires. |
trusted_sources.{domains,agent_ids,ip_ranges} | Platform intersection, org+agent union: platform allowlist is the compliance ceiling; downstream scopes can only add from inside that ceiling. |
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: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)
If an agent’s tool responses contain large payloads and per-request latency matters: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 totrusted_sources so Safe House skips detector runs on content from that source:
trusted_sources. The API validates against a static deny-list and rejects obvious mistakes, but the risk model is on you.
Alerting
Protection-card violations emit webhook events if your org has webhooks configured:Validating changes before deploy
For CI pipelines that publish card changes, validate the card client-side before the API call:--strict flag also checks that the card composes cleanly with the current org template (no conflicts with stricter-wins).
Rolling back a change
There’s no first-class rollback endpoint. To revert:-
Fetch a historical version:
- Pick the version you want, publish it as a new PUT.
See also
- Protection Card — conceptual overview
- Protection Card Schema — normative spec
- Safe House — the detection pipeline this card configures
- Safe House Threat Model — what Safe House defends against
- Safe House Webhooks — alerting integration
- Card Composition Guide — managing org templates and exemptions