Secure engineering patterns
Secure engineering patterns are the implementation layer of the field guide. The earlier docs explain why agentic systems change risk (landscape map), how they fail (threat model), where the failures enter (attack surfaces), how local weaknesses compose (attack chains), and which control layers should sit in the system (defence architecture). This document closes the loop by connecting those control layers to reusable patterns engineers can build to.
The mission is explicit on this connection:
Connect threats to practical defence architecture and secure engineering patterns.
Patterns sit at the level where decisions become code. They are not vendor blueprints. They define the shape of the controls — the boundaries, decision points, audit edges, and deny or revise branches — that make an agentic system observable, interpretable, constrainable, and governable in line with the runtime security model in defence architecture.
Pattern Set
Five patterns cover the boundaries where agentic risk most often becomes action. Each pattern follows the same shape: context, risk, recommended controls, boundary diagram, implementation notes, failure modes covered, evaluation checks, audit evidence, and limitations.
| Pattern | One-line summary | Primary failure modes addressed |
|---|---|---|
| Secure Agent Runtime | The pipeline of named stages around the agent reasoning step that observe, interpret, constrain, and audit every proposed action. | Prompt and instruction attacks; goal hijacking; unsafe autonomous action; monitoring and evaluation blind spots. |
| Secure Tool Calling | A tool broker mediates every call with allowlist, schema validation, policy decision, scoped credential, output validation, and outcome control. | Tool misuse and unsafe composition; instruction attacks reaching action; unsafe autonomous action. |
| Secure MCP And Capability Governance | A registry, server authentication, capability scope check, context isolation filter, and response validation around every MCP server, skill, or extension. | MCP, skill, and extension compromise; tool misuse via packaged capabilities; context poisoning via capability responses. |
| Memory Security | Classification on write, provenance and expiry tags, read policy, freshness and source filter, and anomaly detection around every memory entry. | Memory poisoning; secret persistence; context poisoning via memory recall. |
| Credential And Token Boundaries | A credential broker issues task-bound, least-privilege, short-lived tokens from vault-backed secrets, with secret filters on outputs and exercised revocation paths. | Credential and token misuse; authority over-grant; multi-agent propagation via shared identity. |
These five compose. The runtime pattern enforces that tool calls go through the tool broker, that capabilities come from the registry, that memory writes pass classification, and that credentials are brokered. None of the four sibling patterns can be safely bypassed if the runtime is implemented well. The runtime cannot replace any of them.
How The Patterns Compose
The overview diagram shows the five patterns operating around the secure agent reference architecture in a single picture. Read it as the engineering view of the secure agent reference architecture: the architecture says where decisions sit, the overview says which pattern owns each decision.
- 1Secure agent runtime: intake, policy, guardrail, approval
- 2Secure tool calling | Secure MCP | Credential and token boundaries | Memory security
- 3Observability and audit
A request moves through:
- Runtime intake. The runtime pattern pins task scope, identity, allowlist, and trace identifier.
- Reasoning. The agent proposes a step using source-labelled context.
- Policy decision. The runtime evaluates the proposed step against intent, identity, and risk.
- Tool path. The tool broker validates allowlist and schema; the credential broker issues a scoped token; the MCP capability is authenticated and scope-checked; the context isolation filter narrows what crosses the host-to-server boundary.
- Action. The tool runtime or MCP server executes; output is validated and quarantined where needed; outcome control sits between the runtime and the downstream system.
- Memory. Memory writes are classified, tagged, and policy-checked; reads are filtered and source-labelled.
- Audit. Every stage emits to the audit channel under the same trace identifier.
Every path has a deny, revise, or escalate branch in addition to allow. Every path has an audit edge. This is the contract patterns place on the implementation.
Threat And Surface To Pattern Map
The mapping below ties the failure-mode taxonomy in threat model and the surface map in attack surfaces to the patterns that address them. Use this as a starting checklist when reviewing a system, not as a substitute for the controls in each pattern.
Failure modes to patterns
| Failure mode (from 01-threat-model) | Primary pattern(s) | Supporting pattern(s) |
|---|---|---|
| 1. Prompt and instruction attacks | Secure Agent Runtime | Memory Security, Secure MCP |
| 2. Goal hijacking | Secure Agent Runtime | Secure Tool Calling |
| 3. Tool misuse and unsafe composition | Secure Tool Calling | Secure Agent Runtime, Credential And Token Boundaries |
| 4. Credential and token misuse | Credential And Token Boundaries | Secure Tool Calling, Memory Security |
| 5. Context poisoning | Memory Security (recall path); planned context-poisoning pattern | Secure Agent Runtime, Secure MCP |
| 6. Memory poisoning | Memory Security | Secure Agent Runtime |
| 7. MCP, skill, and extension compromise | Secure MCP | Secure Tool Calling, Credential And Token Boundaries |
| 8. Multi-agent propagation | Planned multi-agent pattern | Credential And Token Boundaries (per-task identity), Memory Security (namespace isolation) |
| 9. Unsafe autonomous action | Secure Agent Runtime (stop conditions, approvals, outcome control) | Secure Tool Calling, Credential And Token Boundaries |
| 10. Monitoring and evaluation blind spots | Secure Agent Runtime (end-to-end trace) | All four siblings contribute audit evidence sections |
Attack surfaces to patterns
| Surface (from 02-attack-surfaces) | Pattern(s) that address it |
|---|---|
| Instruction sources | Secure Agent Runtime |
| Context and retrieval | Secure Agent Runtime, planned context-poisoning pattern |
| Tool interfaces | Secure Tool Calling |
| Credential boundaries | Credential And Token Boundaries |
| Memory and state | Memory Security |
| Code and automation | Planned sandboxing and code execution pattern; partially Secure Tool Calling |
| MCP, skills, and extensions | Secure MCP |
| Human approvals | Secure Agent Runtime, Secure Tool Calling, Credential And Token Boundaries |
| Policy decisions | Secure Agent Runtime |
| Observability and evaluation | Secure Agent Runtime (audit evidence sections in all five patterns) |
| Multi-agent communication | Planned multi-agent pattern |
| Downstream systems | Secure Tool Calling (outcome control), Credential And Token Boundaries |
Chain interruptions to patterns
The interruption checklist in attack chains lists eight defensive questions. Patterns map to those questions as follows:
| Interruption question | Pattern(s) |
|---|---|
| Can untrusted language be prevented from becoming control instruction? | Secure Agent Runtime, Memory Security, Secure MCP |
| Can goal alignment be checked before a risky tool call? | Secure Agent Runtime, Secure Tool Calling |
| Can policy decisions evaluate intent, authority, data sensitivity, and likely impact together? | Secure Agent Runtime, Secure Tool Calling |
| Can credentials be scoped to the task and revoked after use? | Credential And Token Boundaries |
| Can memory writes be reviewed, expired, corrected, and traced? | Memory Security |
| Can cross-agent messages preserve origin, trust level, and delegated scope? | Planned multi-agent pattern |
| Can humans see enough evidence before approving sensitive action? | Secure Agent Runtime, Secure Tool Calling |
| Can the full path from influence to outcome be reconstructed after the fact? | Secure Agent Runtime (linked trace), audit evidence sections in all five patterns |
Reader Paths
The five patterns are written so different readers can pick up the parts they need without reading the whole set. Suggested reading orders:
- AI leaders and CTOs. Start with 00 landscape map and 04 defence architecture. Then read this document and the context, risk, and limitations sections of each pattern. The aim is to understand which boundaries the engineering layer must enforce and what the residual risk looks like.
- AI engineers and security engineers. Start with 01 threat model, 02 attack surfaces, and 03 attack chains. Then read each pattern in full, focusing on recommended controls, boundary diagram, implementation notes, evaluation checks, and audit evidence. Use this document’s threat-to-pattern map as a checklist when reviewing a system.
- Governance leaders. Start with 00 landscape map, 04 defence architecture, and the audit evidence sections of each pattern. The audit evidence sections describe what the organisation should be able to retrieve for assurance, incident response, and accountability.
- Researchers. Start with 10 open research questions, then read the failure modes covered and limitations sections of each pattern to see where current patterns are firmest and where they remain partial.
Relationship To Other Sections
This document is the bridge between the conceptual docs and the patterns. The earlier docs name the problem space; the patterns name the implementation; this document keeps them aligned.
- 00 landscape map — the system-level map this engineering layer protects.
- 01 threat model — the failure modes patterns address.
- 02 attack surfaces — the surfaces patterns guard.
- 03 attack chains — the chains patterns interrupt.
- 04 defence architecture — the control layers patterns implement.
- patterns/ — the patterns themselves.
- visuals/ — the diagrams referenced from each pattern, including the overview.
Patterns are living. As new failure modes, surfaces, or chain patterns are added, the maps in this document should be updated.