AI / LLM security
An LLM is an egress path and an injection surface at once: a prompt can carry context out of the boundary, and a tool result can carry instructions in. System9 governs both with guards that are specific to inference and that hold on both runtimes:
- Inference-egress residency: nothing leaves the boundary until a refuse-closed check passes, resolved live before any context is bound.
- Content guards: untrusted content is delimited, trust-classed, validated against injection, and blocked output is quarantined, with verdict parity between the edge and the core.
Both compose with the platform-wide deny-closed governance and the classification ladder; this page covers only what is specific to LLM inference.
Inference-egress residency: refuse closed before context leaves
Before a single token of context is bound to a request or sent to a model, the inference path resolves the residency of the workspace or clean room and refuses if the model cannot legitimately run inside the pinned boundary. It is the data-residency control applied to the one path that would otherwise leak context: the prompt itself.
The guard composes residency pins with model-egress ownership, most-restrictive wins, and then resolves live against fabric membership, and it is fault-first: if any input to the decision cannot be read, it refuses degraded rather than falling through to allow.
Figure: the inference-egress residency gate. The check runs before context is bound. A load fault on any axis refuses degraded (red), a read fault never silently allows. An unsatisfiable required pin refuses (red) and never degrades to another jurisdiction. No policy originates locally (single-device safe); a satisfiable pin originates at the residency-correct cell (green). The edge and the core keep the refusal codes identical for parity.
Table equivalent
| Situation | Decision | Refusal is because |
|---|---|---|
| Load fault on any residency axis | Refuse (degraded) | A read fault must never fall through to allow |
| Required pin unsatisfiable | Refuse | Never degrade inference to a non-compliant jurisdiction |
| No residency policy | Allow: originate locally | Single-device / pre-pin safe; no regression |
| Required pin satisfiable | Allow: originate at the residency-correct cell | The model runs inside the pinned boundary |
Where it runs. On the edge chat path the residency gate is evaluated before data binding and before the model request is built, on refusal it returns a signed refusal marker carrying the code and reason. The edge guard is authored decision-for-decision against the core guard, and the two keep byte-identical refusal codes so the runtimes cannot drift. This is a two-runtime-parity capability in the sense the platform holds itself to: the same contract, stated once, enforced on both sides.
Content guards: delimit, trust-class, detect, quarantine
The content guards defend the model from instructions smuggled in through data. They run at the choke point where any untrusted content reaches the model.
Untrusted-content delimiting
Every span the model should treat as data to consider rather than instructions to follow, tool output, recalled memory, peer messages, relayed transcripts, catalog text, attachments, authored blueprint text, is wrapped in explicit untrusted-content markers, paired with a system-prompt directive that tells the model the marker contract. The delimiting is idempotent and anti-forge: lookalike or pre-existing markers are stripped before re-wrapping, so untrusted text cannot forge a closing marker or double-wrap on a relay hop.
A trust-class model
Content is classified by trust (operator, model, system, or untrusted) and the safe default is untrusted: an untagged span is treated as untrusted, and untrusted (and operator) content requires validation.
Injection detection with thresholds
An input validator scores content against tiered injection patterns (prompt override, role hijack, delimiter injection, and lower-confidence warn-tier patterns) and also decodes long base64 runs to catch encoded injection. The highest-confidence match wins, and the verdict is block, warn, or allow against fixed thresholds.
Output quarantine
The guard sees the raw, uncapped tool output. A block verdict withholds the payload entirely and replaces it with a guardrail marker naming the technique; anything else is delimited as untrusted before the model sees it. The blocked content never reaches the model.
Verdict parity across runtimes
The edge content guard is a faithful mirror of the core's, and a shared injection corpus pins them together: a parity test asserts the edge produces the same allow / warn / block verdict as the core for every recorded case, so the two guardrails cannot silently diverge.
Related topics
- Chat & LLM, the end-to-end governed chat turn these guards sit in.
- Data residency, the residency control this gate applies to the inference path.
- Security → Governance, the net-effect gate and deny-closed posture.
- Security → Classification, the ladder the output redaction reads down.
- The AI system (core + edge), where these guards fit the whole system.