What gets inspected
Which bytes of your request a guard actually sees — the conditions a field must clear, and the blind spots that follow.
On this page
The Go gateway extracts content from protocol positions and records extraction coverage separately from detector findings. A partial body, an unsupported part, and a completed scan with no findings have different receipts.
Supported text surfaces
| Surface | Inspection scope |
|---|---|
| Chat messages and buffered answers | Message text and recognized text blocks |
| Tool calls | String values in structured arguments, including JSON encoded inside a string |
| Tool results | Recognized tool-result content and function-call outputs |
| Responses API | Input/output items, function-call arguments and outputs |
| Anthropic-style content | Text, tool-use input and tool-result content |
| Tool definitions | Preserved schema and descriptions; excluded from content mutation |
| Metadata, identifiers and provider envelopes | Preserved; arbitrary matching key names do not opt them into inspection |
| Image, audio and video content | No OCR, transcription or semantic inspection |
Mutation uses the extracted source coordinates. Nested JSON-string arguments are escaped back into their original envelope; tool names, IDs, schema keys and metadata stay byte-for-byte intact outside the changed span. Unknown part types and opaque bodies disclose incomplete coverage even when another part was inspected successfully.
Bounds are part of coverage
Extraction is bounded by body bytes, nesting depth, node count and text sites. The current extractor limits are 4 MiB, 64 levels, 65,536 nodes and 4,096 sites. Detector scanners have additional work, candidate and match limits. Exhaustion is a protection failure, not an empty clean result; the receipt carries an authored reason such as scan_exhausted or uninspectable_body.
Whether a protection failure allows bytes through depends on the effective binding’s mode, on_error and acknowledgement. See Phases & streaming. Tool schemas and media remain outside semantic content coverage; a clean text scan says nothing about their contents.
tokentriage guardrails list and the dashboard capability response describe the running build. Ordinary receipts contain bounded coverage metadata and counts, not submitted content or client-controlled JSON key names.
The email detector excludes reserved and documentation top-level domains such as .invalid, .example and .test. A complete scan can therefore leave those email-shaped strings unchanged. The frozen readiness holdout labels eight .invalid cases as positive; the current detector misses all eight and fails that authored floor. A separately derived .com control does not replace the holdout or establish population recall.