Chapter DGuardrails in codePage 6 of 8

Guardrails in code

Add observability and tests

Guardrails in code is production work only when one frozen failure can be reproduced, one measurable gate can stop a release, and one operator can safely reverse it.

~14 minObservability

Before you start

Why this matters

Read this incident aloud: a user asks for an order update while smuggling an extra argument that would refund a different order. In two minutes, write the earliest deterministic check that should fail, the telemetry signal you would inspect, and the action that must not happen automatically. Compare your answer with this chapter's boundary: identity comes from the session, never model output; tools are allowlisted and arguments are schema-validated.

1Learn the idea

Read

Instrument metrics, logs, and traces

Instrumentation should answer four questions from one correlation ID: what release ran, which stage failed, how long each stage took, and what decision was made. Emit structured events, not interpolated prose. A useful event includes event, request_id, trace_id, release, stage, outcome, latency_ms, and a small set of bounded labels. Record guardrail_decision_total as a counter or ratio with stable dimensions; never use request IDs, user text, or error messages as metric labels.

Trace the transaction using a root span and child spans around meaningful boundaries. Add counts, versions, finish reasons, and safe IDs. Do not attach full prompts, retrieved passages, secrets, or tool arguments. Logs explain discrete decisions, metrics detect population changes, and traces reconstruct one request; none replaces the others. Sampling may reduce ordinary success traces, but always retain errors and policy denials under the approved retention policy.

Create an operational test that sends a synthetic request tagged probe=true, then checks that the metric increments, the trace has required child spans, and the log can be found by trace ID. An alert is useful only if it links to a runbook and has a clear action. For this lab, the release rule remains zero unauthorized tool executions and at least 0.95 benign-request pass rate, and the first response is to deny the call, return a neutral response, and emit a redacted audit event.

For observability, test telemetry as a product interface. Assert required span names and log keys, cardinality-safe dimensions, redaction, and alert routing using synthetic events.

Read

Focused implementation artifact

def emit_decision(metrics, logger, *, trace_id, release, outcome, latency_ms):
    metrics.counter("guardrail_decision_total").add(1, {"release": release, "outcome": outcome})
    logger.info("refund_tool_attempt_403", extra={
        "trace_id": trace_id, "release": release,
        "outcome": outcome, "latency_ms": latency_ms,
        "payload": "[REDACTED]",
    })

def test_telemetry(fake_metrics, fake_logger):
    emit_decision(fake_metrics, fake_logger, trace_id="t-1", release="canary", outcome="deny", latency_ms=18)
    assert fake_logger.last["payload"] == "[REDACTED]"

Read

Verify the telemetry path

Create a synthetic request that reaches every normal stage and another that reproduces a keyword filter passes harmless wording but the model emits refund_order with an attacker-controlled customer_id. The success trace must contain a root span and ordered child spans; the failure trace must mark the first broken boundary and skip spans for actions that never ran. Assert context propagation rather than relying on visually similar timestamps.

Emit guardrail_decision_total with release, outcome, and a bounded domain slice. Keep request IDs in logs and traces, never metric labels. A structured log should include trace ID, stage, decision, latency, and policy or model version. Redaction happens before export and is tested against nested secrets and identifiers. Sampling may drop ordinary successes, but it must retain errors and policy denials under the documented retention cap.

Test the alert using synthetic events until it opens the runbook with the correct query. The alert condition derives from unsafe action escape rate and zero unauthorized tool executions and at least 0.95 benign-request pass rate; include window and minimum sample so one request cannot page an entire team. The first response is to deny the call, return a neutral response, and emit a redacted audit event.

Checking tutor…

Continue learning · glossary & guides