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:

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:

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:

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