Skip to main content
The genuinely enforced surface is Tracelane’s deterministic guardrail rails engine (R1–R8, crates/gateway/src/guardrail/, wired inline and exposed at /v1/guardrails/stats) — eight rails, live-proven, that can allow, redact, or block a request at the gateway. Alongside the rails, an observe-first predictive layer (crates/gateway/src/predictive/, the PR1–PR8 predictors below) scores each request and records a verdict. By default it does not enforce — predictive_enforce is false, so a Block verdict is written to the audit trail, not turned into a 403, unless an operator sets TRACELANE_PREDICTIVE_ENFORCE=1. On a plain /v1/chat/completions body only tool_definition_drift and the tool-call schema validator do reachable work; the rest fire only on the specialised span shapes noted per-guard below. The layer’s latency has not been measured on production-equivalent hardware, so no latency figure is published for it.

​
At a glance

Agent-tool safety guardrails (PR1 through PR8) — with per-guard status

​
PR1 — MCP rug-pull detection

Live detection, observe-first. Catches an MCP tool whose schema, description, or pinned hash mutates mid-session. tool_definition_drift + mcp_hash_watcher hash (name, description, input_schema_json) on a request’s declared tools[] on first use; any later mismatch is recorded at the gateway. Enforcement (halt) is opt-in; the enforced tool-pinning path is guardrail rail R3.

​
PR2 — Lethal-trifecta taint tracking

Roadmap / dormant on the gateway chat path. Tracks the three ingredients of agent exfil: untrusted input, private data access, external write. The detector requires a top-level tool_name + tracelane_untrusted_input + a frontier model; a chat-completions body supplies only model, so it never reaches threshold there. The enforced trifecta check is guardrail rail R4 (gated).

​
PR3 — A2UI component-type check

Never runs on the gateway chat path. Checks the type of each Agent-to-UI component (cards, buttons, forms emitted via A2UI) against a fixed list of standard A2UI v0.9 types. There is no per-tenant catalog to resolve against and no rendered-output comparison. It evaluates only on protocol:"a2ui" payloads — never on LLM chat traffic.

​
PR4 — Prompt-injection classifier

Partial / dormant on the chat path. The heuristic pattern layer reads top-level tool_output/content; on a standard chat body the content is nested inside messages[], so the heuristic is dormant there. The ML upgrade — Llama Prompt Guard 2 distilled to ONNX for low-latency CPU inference — is on the roadmap and is not part of the shipped product. The PII/secret redaction that does fire on live traffic is guardrail rail R2, a separate system.

​
PR5 — Browser stuck-loop prediction

Roadmap. Operator agents (Browserbase, Playwright via MCP) can loop on the same page action. The detector uses a sliding window of (URL, DOM-action-fingerprint) tuples, but fires only on browser/operator spans (tracelane.browser.step_index) — not on LLM chat.

​
PR6 — A2A handoff required-field check

Never runs on the gateway chat path. When one agent hands a task to another, the validator checks that the handoff object carries four required fields — handoff_id, from_agent, to_agent, context. It does not verify a signed Agent Card or any other signed origin, does not check task-state legality, and does not detect handoff cycles. It evaluates only on tracelane_message_type A2A envelopes, never on a chat body.

​
PR7 — Output-policy regex + SLM judge

SLM judge is a stub. The SLM judge predictor (1B encoder on L4 GPU) is a constant stub today — it returns “safe” with no model file — so PR7’s judge stage performs no real grading. The live output-policy work (PII, credentials, profanity regex) is the guardrail rails engine (R2/R5/R6), a different system from this predictor.

​
PR8 — Argument drift

Never runs on the gateway chat path. The detector reads a top-level tool_name + tool_args; a /v1/chat/completions body carries neither, so it returns without evaluating. Tracelane does not detect MCP argument-distribution anomalies on live chat traffic. The reachable tool-argument check on that path is the tool-call schema validator, which validates each tool call against the input_schema declared in the request.

​
Configuring per-tenant

Each guard has a per-tenant policy — disabled, warn, or block. Because the predictive layer is observe-first by default, a block policy records a block verdict in the audit trail but does not return a 403 unless an operator enables enforcement (TRACELANE_PREDICTIVE_ENFORCE=1). Policy defaults are shown below; a policy only has an effect for a guard that runs on your traffic — PR2, PR3, PR5, PR6 and PR8 do not run on the gateway chat path (see the table above), so their policy has no effect there:

​
Reading predictive output

Every hit emits a span attribute under predictive.*. The dashboard trace viewer surfaces these in a dedicated lane. The MCP server filters by predictive severity:

​
Performance

There are no measured latency numbers for the predictive layer, combined or per guard; it has not been measured on production-equivalent hardware.