# Implementation Guide > A 12-step process for implementing ACS in your agent environment - **Category**: guardrails-acs - **Canonical URL**: https://designpattern.fyi/guardrails-acs/implementation-guide/ --- ## Description A 12-step process for implementing ACS in your agent environment ## Additional Notes # Step-by-Step Implementation Guide This sequence assumes you're retrofitting guardrails onto an existing agent estate rather than starting greenfield — that's the more common (and harder) enterprise case. --- ## Step 1 — Inventory Your Agent Environment Before instrumenting anything, map what your agents actually touch. ### Use the AOS Environment Model AOS's own environment model is a useful checklist: | Component | Examples | Local | Remote | Related Protocol | |---|---|---|---|---| | User | Chat UI, Slack, email | ✓ | ✓ | — | | Trigger | Schedules, webhooks, inbound notifications | ✓ | ✓ | — | | Other agents | Sub-agents, peer agents | ✓ | ✓ | A2A | | Memory | Session history, long-term store | ✓ | ✓ | — | | Knowledge | Files, RAG indexes, external sources | ✓ | ✓ | MCP | | Prompts | Saved prompt templates | ✓ | ✗ | MCP | | API/OS tools | REST calls, function calls, OS-level actions | ✓ | ✓/✗ | MCP | | LLM | Direct model calls for reasoning or sub-tasks | ✓ | ✓ | — | ### Output of This Step A component list per agent, each tagged with: - Whether it's local or remote - Which protocol (if any) governs it This becomes your: - **Instrumentation checklist** for Step 2 - **Seed data** for your AgBOM in Step 9 --- ## Step 2 — Prioritize Hook Coverage Against Your Risk Profile Don't instrument everything at once. ### Run the Risk Mapping Use the Section 5 mapping table against your actual agent estate: - Which ASI risks are most plausible given what your agents do? - An agent with no code-execution tool doesn't need to prioritize ASI05 mitigations on day one - An agent that writes to shared memory should prioritize ASI06 immediately ### Output A ranked list of hooks to instrument first, based on: - **Risk exposure** — which risks are most likely for your agents - **Business impact** — which failures would be most damaging - **Implementation complexity** — which hooks are easiest to add first --- ## Step 3 — Instrument the Input and Output Boundary First Start with the **User Message** and **Agent Response** hooks. ### Why Start Here - **Cheapest integration point** — every agent has exactly one inbound and one outbound boundary - **Quick wins** — gives you your first working Guardian Agent policy quickly - **High leverage** — catches the crudest attacks immediately ### Minimal Policy Example A minimal policy check at this stage might look like: ``` hook: message (role=user) policy: reject-known-injection-patterns, reject-out-of-scope-topics verdict-on-match: deny (respond with a safe refusal template) verdict-on-clean: allow ``` ### Watch Out For Treating this as sufficient. Input/output filtering alone: - Catches the crudest attacks - Does nothing about poisoned tool results - Does nothing about compromised sub-agents - That's why the next steps matter --- ## Step 4 — Instrument the Tool-Call Boundary The **Tool Call Request** and **Tool Call Result** hooks are the highest-leverage control point. ### Why Tool Calls Matter Almost every consequential action routes through a tool call: - Database writes - Email sends - Payments - File deletions ### Wire Both Request and Result ``` hook: toolCallRequest context: { tool: "send_email", params: {...}, reasoning: "..." } policy: cost-control, data-protection, destructive-action-review verdict: allow | deny | modify(params) hook: toolCallResult context: { tool: "database_query", result: {...} } policy: pii-redaction, result-size-limit verdict: allow | deny | modify(result) ``` ### Watch Out For Policies that only inspect the tool name and not the parameters: - A `deny` on "any database_query" is safe but useless - A policy that inspects the query text for `SELECT *` or unscoped access is the actual control --- ## Step 5 — Stand Up the Guardian Agent as a Real Policy Engine By this point you need a proper enforcement point, not ad hoc checks scattered across hook handlers. ### Guardian Agent Requirements A Guardian Agent — a service (or SDK-embedded component) that: 1. **Receives hook events** over the standardized method calls (see Appendix A) 2. **Evaluates them against declarative policy** — start with data-protection, cost-control, and destructive-action categories 3. **Returns a verdict object with a reason string** — the reason is what makes your later audit trail actually explainable, not just a log of allow/deny flags ### Output A single, testable enforcement point that every future policy change goes through, instead of a policy check duplicated across every agent. --- ## Step 6 — Extend into Memory and Knowledge Hooks Add **Memory Context Retrieval**, **Knowledge Retrieval**, and **Memory Store** hooks. ### Addressing ASI06 (Memory & Context Poisoning) This is where you address memory poisoning directly: - Gate what gets *written* to memory (so an attacker can't plant instructions for a future session) - Gate what gets *read* back into context (so stale or poisoned entries don't silently resurface) ### Watch Out For Only gating the write path: - Poisoned content that entered memory before you had this control is still sitting there - The read-path gate is what catches it going forward - You may need a one-time memory audit as well --- ## Step 7 — Extend into MCP and A2A Protocol Traffic If your agents call remote MCP servers or delegate to other agents over A2A, instrument the protocol-level hooks. ### Protocol-Level Hooks - **MCP Outbound/Inbound** — for Model Context Protocol traffic - **A2A task-delegation, cancellation, and status hooks** — for inter-agent communication ### Addressing ASI04 and ASI07 This is where: - **ASI04 (Supply Chain)** gets addressed — allow-listed set of MCP servers - **ASI07 (Insecure Inter-Agent Communication)** gets addressed — authenticated, policy-checked A2A handoffs rather than implicit trust between agents --- ## Step 8 — Wire Up Trace Emit OpenTelemetry spans with agent-specific attributes for every hook firing from Steps 3–7. ### Trace Attributes For every hook, emit spans with: - **Session ID** — track interactions across time - **Agent name** — identify which agent performed the action - **Reasoning steps** — understand agent decision-making - **Tools called** — see what actions the agent attempted ### Map to OCSF Map the security-relevant subset of those events to OCSF and forward them to whatever SIEM your security team already operates. ### Goal An incident responder should be able to reconstruct a multi-agent workflow's full decision chain without needing bespoke tooling per agent framework. --- ## Step 9 — Generate and Maintain a Dynamic AgBOM Using your Step 1 inventory as a starting point, generate an initial AgBOM. ### Initial AgBOM Generate in CycloneDX or SPDX format capturing: - Every model per agent - Every tool per agent - Every knowledge source per agent ### Make It Dynamic Wire AgBOM regeneration into your capability-discovery events: - New MCP server connected - New tool registered - Model switched ### Output A living inventory you can diff against policy — "this agent just gained access to a new tool; is that tool approved?" --- ## Step 10 — Layer in Tier 3 Enterprise Classifiers Bring your organization's own detectors into the Guardian Agent. ### Enterprise Classifier Examples - **PII/PHI detectors** — data sensitivity classification - **Cost control** — budget monitoring and alerting - **Jurisdiction-specific rules** — data residency requirements - **Industry-specific rules** — sector-specific regulations ### This is the Tier where... - Financial services bring a data-sensitivity model - Healthcare brings PHI detection - You bring whatever security tooling you already trust --- ## Step 11 — Map Controls to Regulatory Requirements Build an explicit crosswalk from your instrumented hooks to the compliance language your legal and risk teams need. ### EU AI Act Article 14 (Human Oversight) - **Requirement:** Natural persons can monitor, understand, intervene in, and halt high-risk AI systems - **ACS Mapping:** The deny/modify verdict at any hook plus the Trace audit record ### NIST AI RMF MEASURE/MANAGE Functions - **Requirement:** Continuous monitoring and the demonstrated capacity to disengage an autonomous system operating outside acceptable parameters - **ACS Mapping:** Runtime hook evaluation + trace-based monitoring + deny verdict as disengagement ### Output This crosswalk is what turns your implementation into audit-ready evidence rather than an engineering exercise nobody outside the team understands. --- ## Step 12 — Establish an Ongoing Governance Cadence Guardrails aren't a one-time build. At minimum: ### Regular Review - **Review Guardian Agent verdict logs** on a fixed cadence (weekly for new deployments, monthly once stable) - **Tune policy thresholds** based on false-positive/false-negative rates ### Testing - **Red-team new and changed agents** against the ASI01–ASI10 scenarios from Section 5 before they go to production ### Maintenance - **Re-check the AgBOM** against your approved-component list whenever an agent's capabilities change ### Community Contribution - **Feed what you learn back into the open standard** — ACS and AOS are both actively soliciting implementation feedback, and issues found in production are exactly what a public-preview spec needs --- ## Implementation Timeline Considerations ### Phased Approach Don't try to implement all 12 steps at once: - **Phase 1 (Weeks 1-4):** Steps 1-3 — inventory, prioritization, input/output hooks - **Phase 2 (Weeks 5-8):** Steps 4-6 — tool hooks, Guardian Agent, memory hooks - **Phase 3 (Weeks 9-12):** Steps 7-9 — protocol hooks, trace, AgBOM - **Phase 4 (Weeks 13-16):** Steps 10-12 — enterprise classifiers, compliance mapping, governance ### Success Metrics Define what success looks like at each phase: - **Phase 1:** Input/output filtering catching obvious attacks - **Phase 2:** Tool misuse prevention working reliably - **Phase 3:** Full observability and inventory established - **Phase 4:** Compliance requirements met and governance cadence established --- ## Key Takeaways 1. **Start with inventory** — you can't govern what you don't know exists 2. **Prioritize based on risk** — focus on highest-impact hooks first 3. **Begin with input/output** — cheapest integration point with quick wins 4. **Build the Guardian Agent early** — centralize policy enforcement 5. **Make it dynamic** — AgBOM and policies should update automatically 6. **Map to compliance** — connect technical controls to regulatory requirements 7. **Establish governance** — guardrails require ongoing maintenance and review --- ## Next Steps - **Reference Architecture** — see the complete system design - **Governance Checklist** — assess your implementation maturity