Guardrail Posture turns passive detection from your instrumented agents into a clear picture inside Traccia. It answers, for each run and over time: which guardrail categories showed up, which ones fired, which ones the SDK expected but did not see, and how strong that signal is. Posture is read-only observability: it reflects what your traces contain; it does not block, rewrite, or approve traffic on its own.

Detection data is produced by the Traccia SDK when you use traccia.init() and optional explicit guardrail spans. For how findings and summaries are built, see Guardrail Detection in the SDK docs.

Guardrail Posture and Policies are different

Policies are rules you define in the product for evaluation, alerting, and governance. Guardrail Posture is derived from trace data: what the SDK observed or inferred for that execution. A triggered category in Posture means the run recorded a guardrail signal; it is not the same thing as a policy violation unless you connect them in your own workflows.

On the trace: Guardrail Posture card

When you open a trace that includes guardrail data, Traccia shows a Guardrail Posture card at the top of the trace view. It aggregates the root trace’s summary so you get one coherent view of that run before you drill into individual spans.

Area	What you see
Coverage confidence	A qualitative label (for example high, medium, or low) for how reliable the SDK considers its own detection on this trace. It describes signal quality for the summary—not a score for how “safe” the agent is.
Findings	The count of structured guardrail findings attached to the trace (explicit integrations, provider-native signals, heuristics). Expand the section to see each finding’s name, status (such as triggered or present), confidence, and how it was sourced.
Triggered	Categories where a guardrail actually fired or blocked for this run. These align with category chips and the findings list.
Missing	Categories the SDK treats as expected for this kind of run but did not observe—often with a short explanation of why the category matters (for example, the agent called an LLM with user-like content but no input-validation signal was recorded).
Detected	Categories where some guardrail activity or expectation was recognized; use this to scan coverage at a glance alongside triggered and missing.

From a finding row you can jump to the relevant span in the timeline when evidence is linked. If a detection is a known false alarm for your workload, you can mark it as a false positive for that trace. That preference is saved for your workspace and dims the finding in the UI; underlying trace data is unchanged, so exports and raw spans stay intact.

If you configure missing-category suppressions for the agent (see below), those categories are omitted from the Missing section on this card. Triggered and detected signals are never hidden by suppression—only “missing” reporting is adjusted so the view matches how you run that agent.

On the agent: Guardrail Posture module

Each agent has a Guardrail Posture module on its overview page. It rolls up traces in the time range you select in the app (for example last 24 hours or seven days), so you can spot patterns instead of reading traces one by one.

·Coverage confidence mix — How often traces in the window landed in each confidence band, so you can see whether summaries are usually trustworthy or often thin.
·Top triggered categories — Which guardrail types fire most often across runs (for example PII or content filters), useful for prioritizing reviews or SDK coverage.
·Recurring missing categories — Categories that show up often as “missing” in the rollup, with the same explanatory context you see on a single trace.
·Recent runs — A compact list of recent traces with quick tags for triggered or missing categories so you can jump back into specifics.

Suppressions you save here apply to missing-category presentation in this module and on the trace Guardrail Posture card for that agent. They do not change triggered counts, findings, or what was actually recorded in each trace.

Missing-category suppression

Heuristics may flag a category as “missing” even when your product handles that risk outside the SDK—for example custom validation in another service, or a category that does not apply to a specialized agent. Suppression lets you remove specific categories from missing rollups and from the Missing list on the trace card, so your Posture views stay actionable and aligned with how you operate.

What suppression does not change

Suppression does not turn off the SDK, alter what is exported to your backend, or hide categories that triggered. It only affects how “missing” categories are reported in Traccia for that agent (within your workspace context).

You can adjust suppressions from the agent’s Guardrail Posture module; changes apply to future views of traces and rollups for that agent.

When you will not see Guardrail Posture

Traces that were captured without guardrail summaries do not show the card—typically because the workload was not instrumented with the Traccia SDK, or runs with an older client that did not emit summaries. Enabling Guardrail Detection and shipping traccia.init() in your agent process is the path to consistent Posture across the product.

Get detection data into Traccia

Follow the Guardrail Detection guide to register automatic processing, add explicit guardrail spans where you need them, and understand categories, confidence, and source types end to end.