Secure Architecture & Patterns

A secure agentic architecture separates concerns, enforces policy at every boundary, and assumes any component may be compromised.

4.1 Reference Architecture

A high-level, secure architecture for agentic systems:

1. API Gateway / UI – AuthN (SSO/OIDC), rate limiting, coarse authZ
2. Agent Orchestrator – Context assembly (prompts, memory, RAG), policy enforcement and guardrail invocation, tool selection and mediation
3. Model Gateway – Abstracts LLM providers, centralizes secrets and request policies
4. Tool / MCP Layer – Narrowly scoped functions behind API authZ and schemas, includes internal microservices and external SaaS
5. Data Layer – Databases, RAG/vector stores, object storage with tenant-aware, row/document-level access controls
6. Observability & Governance – Shared logging, monitoring, auditing, configuration management

Threat model each boundary: UI ↔ orchestrator, orchestrator ↔ LLM, orchestrator ↔ tools, tools ↔ data.

4.2 Plan–Verify–Execute Pattern

Critical for high assurance. Ensures no single compromised reasoning step can cause harm.

1. Plan (read-only agent)

• Only has read tools (RAG, search, metadata).
• Produces a structured plan: a sequence of proposed tool calls with scopes.

2. Verify (policy engine)

Deterministic code (not the LLM) evaluates:

• Agent's permissions (tools, data domains)
• Risk of each step (read vs write, bulk operations, regulated data)
• Need for breakpoints/human approval

3. Execute (limited executor)

• Executes only the approved steps with scoped credentials.
• Any deviation (new steps, new tools) must go back through verification.

4.3 Controlled Breakpoints (Graduated Autonomy)

Classify actions by risk:

Low Risk

Read-only queries, summarisation, internal search

• Autonomy allowed; log actions.

Medium Risk

Single record updates, sending single emails internally

• Autonomy acceptable with explicit logging and anomaly monitoring.

High Risk

Bulk updates, deletions, external communications, financial transactions, config changes

• Require breakpoints:
• Agent proposes an action (with diff/preview)
• Human or policy service approves/rejects/modifies

Implement as structured "proposed action" objects, not free text.

4.4 Task Decomposition and Isolation

Avoid the "lethal trifecta" in one process:

1. Highly sensitive data
2. Untrusted content
3. Broad network access or powerful side-effect tools

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

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

4.5 Multi-Agent Consensus for Critical Actions

For very high impact decisions:

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

Use this where the cost of a wrong action is extremely high (e.g., security changes, major financial moves).