Chapter 4

Secure Architecture and Patterns

A secure agentic architecture separates concerns, enforces policy at every boundary, and assumes any component may be compromised. These patterns give you concrete ways to build that into your system from the start.

Architecture

4.1 Reference Architecture

A high-level, secure architecture for agentic systems. Each layer has a specific job, and each boundary between layers is a place where you enforce security controls.

1. API Gateway / UI

Handles authentication (SSO/OIDC), rate limiting, and coarse authorization. This is the front door. Lock it.

2. Agent Orchestrator

Assembles context (prompts, memory, RAG), enforces policies, invokes guardrails, selects tools, and mediates every interaction between the model and the outside world.

3. Model Gateway

Abstracts LLM providers, centralizes secrets and request policies. Lets you swap providers or models without touching the rest of the stack.

4. Tool / MCP Layer

Narrowly scoped functions behind API authorization and schemas. Includes both internal microservices and external SaaS integrations.

5. Data Layer

Databases, RAG/vector stores, and object storage with tenant-aware, row/document-level access controls. Data access is never direct from the model.

6. Observability & Governance

Shared logging, monitoring, auditing, and configuration management across all layers. If you cannot see it, you cannot secure it.

Threat model each boundary: UI to orchestrator, orchestrator to LLM, orchestrator to tools, tools to data. Every crossing is a place where assumptions change and controls must be re-evaluated.

Pattern

4.2 Plan-Verify-Execute Pattern

Critical for high-assurance workflows. This pattern ensures no single compromised reasoning step can cause harm. It works by splitting agency into three distinct phases with different trust levels.

Step 1

Plan (Read-Only Agent)

The planning agent only has read tools: RAG retrieval, search, metadata lookups. It produces a structured plan - a sequence of proposed tool calls with defined scopes. No writes, no side effects.

Step 2

Verify (Policy Engine)

Deterministic code (not the LLM) evaluates the plan. It checks the agent's permissions, assesses the risk of each step (read vs. write, bulk operations, regulated data), and identifies steps that need breakpoints or human approval.

Step 3

Execute (Limited Executor)

Executes only the approved steps with scoped credentials. Any deviation - new steps, new tools, parameter changes - must go back through verification. No freelancing.

Use this pattern for:

  • Finance - payments, transfers, invoice processing
  • DevOps - deployments, infrastructure changes
  • HR/Identity - role and permission changes
  • Any bulk data modification or export

The key insight: the model proposes, but deterministic code decides. The plan is just a suggestion until verified code approves it.

Graduated Autonomy

4.3 Controlled Breakpoints

Not every action carries the same risk. Classify agent actions by impact level, and match autonomy to risk.

Low Risk

Read-only queries, summarization, internal search. Autonomy is fine here. Log the actions for audit, but do not require approval.

Medium Risk

Single record updates, sending individual emails internally. Autonomy is acceptable with explicit logging and anomaly monitoring. Watch for patterns, not individual actions.

High Risk

Bulk updates, deletions, external communications, financial transactions, configuration changes. These require breakpoints: the agent proposes an action (with diff/preview), and a human or policy service approves, rejects, or modifies it.

Implement breakpoints as structured "proposed action" objects, not free text. A structured object can be validated, diffed, and audited. Free text cannot.

Isolation

4.4 Task Decomposition and Isolation

Avoid the "lethal trifecta" in a single process:

  • Highly sensitive data
  • Untrusted content
  • Broad network access or side-effect tools

At most, a single component should ever see two of these at once. Never all three.

In practice, this means:

  • Break workflows into smaller steps with distinct roles and permissions
  • Run code execution and parsing in isolated sandboxes with no default network access
  • Restrict which tools can run in the same context

If your agent can read sensitive customer data, parse untrusted web content, and make outbound HTTP calls all in the same execution context, you have created an exfiltration pipeline. Decompose the workflow so that no single component has all three capabilities at once.

Redundancy

4.5 Multi-Agent Consensus for Critical Actions

For decisions where the cost of getting it wrong is very high, a single model's judgment is not enough.

  • Use multiple agents (possibly with different models or different prompts) to independently evaluate the same decision
  • Require consensus (e.g., 2 of 3 agree) before executing
  • If disagreement exceeds a threshold, route the decision to a human rather than forcing a resolution

This adds latency and cost. Use it selectively, where the stakes justify it: security-critical configuration changes, major financial transactions, access control modifications, or any action that is difficult to reverse.

The point is not that multiple models are more capable than one. The point is that an attacker who can manipulate one model's reasoning would need to simultaneously compromise multiple independent evaluation paths, which is significantly harder.

Building agentic AI? Get the architecture right from day one.

We review agentic system architectures and help teams identify gaps before they become incidents. Let's talk about your design.

Get in touch