Why architecture matters here
Agentic products fail not on model quality but on operational safety. A prompt-injected email agent that sends a mass unsubscribe, an over-privileged CI agent that deletes a repository, a customer-support agent that issues refunds outside policy — every one of these is a governance gap, not a model gap.
The architecture matters because you cannot bolt governance on later. You need policy at admission, approvals at high-risk actions, audit on every decision, and a replay path so incidents become policy updates. All of that must be present at day one; adding it after a launch means a rewrite.
With this plane, security teams can sign off on agent deployments, compliance can produce evidence, and product teams can iterate on features without breaking safety.
The architecture: every piece explained
The top strip is the decision path. Agent runtime hosts the planner and executes tool calls; every call is intercepted before it leaves the process. Policy engine — OPA or Cedar — evaluates rules: which tools this user may call, which resources they may touch, what shape the arguments must have. Approval broker handles the human-in-the-loop path: high-risk actions pause and page a designated approver via Slack, email, or a governance console. Guardrail LLM classifies inputs (jailbreak, injection, PII) and outputs (harmful, off-policy) and can veto both.
The middle row is the substrate. Tool registry holds signed, versioned tool definitions with schemas, risk bands, and required policies; nothing runs off-registry. Session store is the auditable trace — every prompt, plan step, tool call, result, and guardrail verdict. Risk scorer assigns each action a band (low / medium / high) that drives the policy engine's decision. Rate + spend caps are hard limits per user, per project, per tool — a bug cannot burn a budget.
The lower rows are the operator surface. Governance console is where security teams edit policy, approvers review pending actions, and product managers see live metrics. SIEM export streams every decision to your log aggregation for auditors and oncall. Post-incident review loop replays traces from incidents, extracts new rules, and ships them back to the policy engine — governance is a feedback system, not a static gate.
End-to-end flow
End-to-end: a user asks an agent to "reconcile the accounts for Q2." The runtime plans four steps. Step 1 (read ledger) is low risk; the policy engine allows it; guardrails pass; the tool runs and results are logged. Step 2 (post journal entry) is high risk; the risk scorer marks it high; the policy engine returns "approval required." The approval broker pages the finance controller in the governance console. The controller reviews the proposed entry, approves, and the tool executes. Step 3 (send email) triggers guardrails on output — a PII detector redacts a client name; the runtime is instructed to re-plan. Step 4 completes cleanly. Every decision is written to the session store and streamed to SIEM. The next week, an incident review shows that step 2 was approved without checking a related invoice; a new policy rule is added requiring cross-reference before high-risk journal entries. The rule ships to the policy engine and the whole flow gets safer.