# Three Pillars > Understanding Instrument, Trace, and Inspect — the foundation of ACS/AOS - **Category**: guardrails-acs - **Canonical URL**: https://designpattern.fyi/guardrails-acs/three-pillars/ --- ## Description Understanding Instrument, Trace, and Inspect — the foundation of ACS/AOS ## Additional Notes # The Three Pillars: Instrument, Trace, Inspect ACS/AOS organizes guardrails into three complementary layers. None of them is sufficient alone — a system that only traces after the fact can't stop anything; a system that only inspects components doesn't know what they *did*. --- ## 1. Instrument — Runtime Hooks and the Guardian Agent ### The Observed Agent An **Observed Agent** exposes standardized hooks at every meaningful decision point in its execution loop: - Input received - Tool about to be called - Memory about to be written - Output about to be sent - And more (see the full hooks reference) ### The Guardian Agent A **Guardian Agent** — your policy-enforcement point — intercepts the hook, evaluates the action against policy, and returns one of three verdicts: | Verdict | Effect | |---|---| | `allow` | The action proceeds unchanged. | | `deny` | The action is blocked entirely. | | `modify` | The action proceeds, but with Guardian-Agent-supplied replacement content. | ### Deterministic Inline Gates This is a deterministic, inline gate — evaluated *before* the action reaches production systems, not sampled or reviewed afterward. ### Why This Matters - **Real-time intervention** — stops bad actions before they execute - **Policy centralization** — single enforcement point for all controls - **Standardized interface** — works across different agent frameworks - **Audit trail** — every evaluation is logged with reasoning --- ## 2. Trace — Structured Observability ### Every Hook Emits a Trace Record Every hook firing, reasoning step, and lifecycle event emits a structured trace record: - **Session IDs** — track interactions across time - **Reasoning steps** — understand agent decision-making - **Tools called** — see what actions the agent attempted - **Lifecycle events** — monitor agent health and status ### OpenTelemetry Integration AOS extends **OpenTelemetry** with agent-specific semantic conventions: - Rather than inventing a competing tracing standard - Agent-specific attributes (session ID, agent name, reasoning steps, tools called) - Integrates with existing observability infrastructure ### OCSF Mapping Security-relevant events map to the **Open Cybersecurity Schema Framework (OCSF)**: - Flow into SIEM systems enterprises already run - Standardized security event format - Cross-agent compatibility ### Forensic-Grade Audit Trail The result is a forensic-grade, cross-agent audit trail — the record you'd pull during an incident to reconstruct exactly what an agent did, why, and on whose behalf. ### Why This Matters - **Incident response** — reconstruct agent behavior during security incidents - **Compliance** — demonstrate oversight and intervention capabilities - **Debugging** — understand agent decision-making patterns - **Optimization** — identify performance bottlenecks and failure modes --- ## 3. Inspect — The Agent Bill of Materials (AgBOM) ### You Can't Govern What You Can't Inventory The foundational principle: you can't govern what you can't inventory. ### Extending Existing BOM Standards Rather than invent a new BOM format, AOS extends three existing, industry-proven ones: - **CycloneDX** — widely used for software supply chain security - **SPDX** — standard for software package data exchange - **SWID** — Software Identification Tags ### What the AgBOM Captures The AgBOM captures every component an agent uses: - **Tools** — function calls, APIs, utilities - **Models** — LLMs, embeddings, specialized models - **Capabilities** — skills, permissions, access rights - **Knowledge sources** — RAG indexes, files, databases - **Dependencies** — libraries, frameworks, MCP servers ### The Key Difference: Dynamic Inventory An **AgBOM is dynamic** — unlike conventional SBOMs: | Aspect | Conventional SBOM | AgBOM | |---|---|---| | **Generation** | Once at build time | Continuously at runtime | | **Updates** | Manual rebuild process | Automatic on capability discovery | | **Scope** | Static dependencies | Dynamic tool/model connections | | **Discovery** | Build-time analysis | Runtime capability detection | ### Why Agents Need Dynamic Inventory Agents discover new tools, connect to new MCP servers, and modify their own capability set at runtime: - **Capability discovery** — agents find and adopt new tools during execution - **MCP connections** — agents connect to new Model Context Protocol servers - **Model switching** — agents may use different models for different tasks - **Knowledge updates** — agents access new data sources and RAG indexes The inventory has to update continuously rather than being generated once at build time. ### Why This Matters - **Supply chain security** — track and approve agent components - **Compliance** — maintain approved component lists - **Risk assessment** — evaluate new tools before adoption - **Auditability** — demonstrate component governance --- ## How the Three Pillars Work Together ### None Is Sufficient Alone Each pillar addresses a different aspect of agent governance: | Pillar | Addresses | Insufficient Alone Because | |---|---|---| | **Instrument** | Real-time control | Without trace, no audit trail; without inspect, no inventory | | **Trace** | Observability | Can't stop actions, only record them after the fact | | **Inspect** | Inventory | Doesn't know what components actually *did* | ### The Combined Value Together, the three pillars provide: 1. **Preventive control** — Instrument stops bad actions before execution 2. **Detective visibility** — Trace records what happened and why 3. **Corrective governance** — Inspect maintains approved component inventories ### A Complete Governance Stack The three pillars form a complete governance stack: - **Before the action** — Instrument evaluates and allows/denies/modifies - **During the action** — Trace records the decision and execution - **After the action** — Inspect updates the inventory and detects changes --- ## Key Takeaways 1. **Instrument provides real-time control** — Guardian Agent evaluates hooks and returns verdicts before actions execute 2. **Trace provides observability** — OpenTelemetry and OCSF integration create forensic-grade audit trails 3. **Inspect provides inventory** — Dynamic AgBOM tracks all agent components at runtime 4. **None is sufficient alone** — Each pillar addresses a different aspect of governance 5. **Together they provide complete coverage** — Preventive, detective, and corrective controls --- ## Next Steps - **Three-Tier Architecture** — see how the pillars are implemented across platform, enforcement, and enterprise layers - **OWASP Risk Mapping** — understand which ACS controls address which agentic risks - **Implementation Guide** — follow the step-by-step process to deploy the three pillars