Guard

Guard is a set of safety checks the platform runs on your inference requests. It looks at what goes into a model and what comes back, and acts when something looks unsafe, such as an attempt to hijack the model’s instructions. You will find Guard under Services > Guard.

​

Turning Guard on

Use the Enabled switch in the top right of the page. It takes effect the moment you flip it, so there is no separate save step. While it is off, requests pass through without any checks.

​

Shadow or enforce

Guard runs a workspace in one of two modes, and this is the first thing to set.

• Shadow. Records what each check would have done, without acting on live traffic. Nothing is blocked and nothing is rewritten. This is where a workspace starts.
• Enforce. Acts.

Shadow is the state that surprises people, because Guard is running and refusing nothing, so the page carries an alert while you are in it. While you are in shadow, a Shadow insights section shows what enforcing would have done, which is what you graduate from.

​

The two checks

Guard has two detectors, shown as two rows.

• Prompt injection. A self-hosted EU classifier for jailbreak and injection attempts. Content never leaves for a third party. It reads a prompt, so it runs on the way in.
• Custom terms. Words and phrases you choose, matched literally and case-insensitively.

Content moderation was withdrawn from the product in September 2026.

​

What a check does when it fires

Each detector carries one control, and Off is one of its values rather than a separate switch:

• Off. The check does not run.
• Allow (log only). Let the request through, but record that the check fired. Useful while you are getting a feel for how often it triggers.
• Flag. Mark the request as flagged and let it continue.
• Block. Stop the request and return an error. Nothing is sent to a model.
• Redact. Remove the matched text before the request continues.

Redact is offered for custom terms only. Redacting means rewriting the text where the match sits, and only custom terms knows where that is. The injection classifier scores a whole message and returns no offset, so a redact rule there would be recorded and audited while leaving the content untouched. The control does not offer it rather than accepting it and doing nothing.

​

Sensitivity

Each detector has a Sensitivity, chosen from a named ladder rather than typed as a number:

• Strict. Catches weaker attempts, and reports more false alarms.
• Balanced. The default. Catches clear attempts.
• Lenient. Only the most obvious attempts.

Each level is a stored score underneath, so a value set through the API that sits between two levels is shown as Custom.

​

Streamed answers

Checks on the way in run before anything is sent to a model, so they always act in time. Checks on the way out run on the answer, and an answer that is streamed is already leaving as it is written. Streamed answers lets you choose which of those two you would rather have.

• Async, the default. The answer streams as it is generated and the output checks run when it finishes. A block is reported after the answer has been shown. A redaction never reaches the reader at all: they have seen the words the rule removes, and only the copy the platform stores is rewritten.
• Buffered. The output checks act before anything is delivered. A blocked answer is never shown and a redacted one is only ever shown rewritten. The cost is the wait: the whole answer arrives at once instead of appearing as it is written.

Buffered holds an answer back only where there is something to wait for. A request still streams under it when no check covers the output, when Guard is in shadow mode, and when Guard is off. Neither setting turns a block into an error status on a streaming API request, because the status is sent with the first chunk. See Streaming for what a streaming caller receives in each case.

​

Metering and records

Each check is metered, so it shows up in your usage. Every time Guard acts, it writes an entry to the audit log under Platform > Audit logs. As everywhere on the platform, those entries record what Guard decided, never the content of your request. A refusal names the check that caused it. Both the error you get back and the log entry say which detector fired, rather than reporting that something was blocked and leaving you to guess. That is the difference between an error you can act on and one you can only retry. In Akumi Chat a refusal ends the message, not the conversation. The blocked turn is marked and the thread stays usable, so you can rephrase and carry on rather than starting again.

​

Good to know

Guard must be enabled. If the Enabled switch is off, no checks run, whatever the detectors are set to. Settings belong to a workspace. The mode, the detector actions and the sensitivities are stored per workspace, so two workspaces in the same organization can run Guard differently, and one can be enforcing while another is still in shadow. Block is final, and where it lands decides what it costs. A request blocked on the way in never reaches a model, so nothing is billed for inference. An answer blocked on the way out is a different thing: the model has already produced it and the provider has already charged us for it, so that request is billed for the inference exactly as a delivered answer would be. The checks themselves are metered either way.