AI Agent Harness and Context Engineering Security: Controlling What Agents See and Can Call

The harness around a model, not the model itself, decides what an agent sees, remembers and is allowed to do, yet it is rarely treated as a security boundary. Context engineering, the practice of curating which tokens reach the model at each step, is now how agent builders get reliable behaviour: system prompts, tool definitions, retrieved documents, memory notes, compacted history and sub-agent summaries are assembled by code on every turn. Each of those inputs is a place where untrusted content can enter and where authority can leak. This guide treats the harness as a control point: it maps each context source to its risk, sets out the controls the harness should enforce outside the model, and explains how to test and monitor them. It is for agent platform engineers, AI security architects and reviewers of agent designs.

Key takeaways

• The harness is the policy enforcement point: anything the model is asked to enforce through its prompt can be talked out of it; permissions, approvals and data filters belong in harness code.
• Every context source has a trust level: label system instructions, user input, tool output, retrieved content, memory and sub-agent summaries, and never let lower-trust content arrive looking like instructions.
• Context management steps are attack surface: just-in-time retrieval, compaction and note-taking can import or launder injected text into later turns.
• Keep secrets out of context: OWASP says the system prompt should not be treated as a secret or used as a security control, so credentials stay in the harness and tools.
• Log the assembled context: without a record of what the model actually saw at each step, incidents cannot be explained.

What the harness and context engineering are

An agent harness is the software that wraps a model: it builds the prompt, exposes tools, runs the loop of model call, tool call and result, manages memory and decides when to stop. Anthropic's engineering team describes context engineering (September 2025) as the set of strategies for curating and maintaining the optimal set of tokens during inference, aiming for the smallest set of high-signal tokens. The components it lists are system prompts, tools, examples, message history, just-in-time retrieval, compaction, structured note-taking outside the context window, and sub-agents that work in clean contexts and return condensed summaries.

Those are engineering techniques for quality. The security consequence is that the harness, not a human, is deciding at runtime what enters the model's context and what the model can reach. Tool-level controls are covered in the AI Agent Tool and Plugin Security Guide and persistent memory in the AI Agent Memory Security Guide. This guide covers the assembly layer between them.

Context sources and their risks

The pattern behind most rows is the same: the model cannot reliably tell instructions from data, so the harness must keep track of where each piece of text came from and act on that, rather than hoping the model will. See the MITRE ATLAS AML.T0080 guide for the attack itself.

Controls the harness must enforce outside the model

• Authorisation in code: each tool call is checked against the acting user's or agent's entitlements before execution. OWASP LLM07 notes the real risk is applications that delegate session management and authorisation checks to the model.
• Least agency: expose only the tools the current task needs, and drop write tools once a step no longer needs them. OWASP LLM06 Excessive Agency recommends minimising extensions, their functionality and their permissions.
• Human approval for high-impact actions: payments, deletions, external sends and permission changes pause for confirmation shown outside the model's output.
• Segregate external content: OWASP LLM01 recommends separating and identifying untrusted content; wrap it in clear delimiters and tell the model it is data, while accepting that this reduces rather than removes risk.
• Taint tracking: once low-trust content enters the context, the harness can restrict the remaining turn, for example by blocking outbound sends or requiring approval. This is our recommended default for agents that read the web or inbound email.
• Output handling: treat model output as untrusted input to downstream systems (OWASP LLM05): no direct shell, SQL or HTML rendering without validation.
• Budgets and stop conditions: step, token, cost and time limits enforced by the harness, with a kill switch. See the AI Agent Kill Switch and Containment Guide.

Securing context management techniques

Just-in-time retrieval

Agents that hold references (file paths, queries, links) and load content on demand reach more data than any static prompt. Run retrieval with the caller's identity, not a broad service account, so the agent cannot read documents the user could not. Restrict which paths, repositories and domains the loader may open, and route web fetches through an egress proxy. See the Agent Egress Control and Network Isolation Guide.

Compaction

When the harness summarises a full context window and starts a new one, any injected instruction in the old window can be restated as a neutral fact in the summary. Keep untrusted spans out of summaries where possible, preserve a trust label on anything carried over, and retain the original window for investigation.

Structured notes and memory

Notes written outside the window persist across sessions, so a single injection can affect future users or tasks. Record the source of each entry, scope memory per user or tenant, and review or expire agent-written entries.

Sub-agents

Sub-agents with clean contexts can be a security tool: a quarantined sub-agent reads untrusted content with no tools and returns structured, schema-checked data to a privileged lead agent. The reverse design, where a sub-agent with broad tools reads untrusted content, spreads risk. Give each sub-agent its own identity and minimal credentials. See the Agent Identity and Access Guide.

Where identity fits

The harness holds the agent's credentials, so it is also where non-human identity controls apply. Keep API keys and tokens in a secrets manager and inject them into tool calls server-side, never into context. Use short-lived, audience-restricted tokens per tool; the MCP security best practices say MCP servers must not accept tokens that were not explicitly issued for them, and recommend progressive, least-privilege scopes rather than requesting every scope up front. Record which human the agent acts for on every call so audit trails survive delegation. See the MCP Security Guide.

Choosing a harness architecture

Small teams building on a hosted agent platform should focus on tool scoping, approvals and secrets handling, which are customer-side settings. Teams running their own harness at scale should add taint tracking, quarantined readers and full context logging.

How to implement

The steps below are NHI Mgmt Group recommendations.

1. Map the context pipeline: for each agent, list every source that can enter the context and every tool it can call, with the identity used.
2. Assign trust labels: classify each source using the table above and record it in the agent's design record.
3. Move rules out of prompts: find any permission, limit or data rule expressed only in the system prompt and implement it in harness code.
4. Remove secrets from context: scan prompts, tool descriptions and memory stores for credentials; move them to the secrets manager.
5. Add approvals and budgets: start in log-only mode to tune thresholds, then enforce.
6. Test with injection cases: plant instructions in documents, tool results and memory in a test environment and confirm the harness blocks the resulting actions. See the AI Agent Security Testing Checklist.
7. Roll out by risk: read-only agents first; keep a configuration switch to disable write tools quickly if a control misbehaves.

Detection and measurement

Log, per step, the assembled context (or hashes and source references where content is sensitive), the tools offered, the tool chosen with arguments, the policy decision and the approver. Alert on tool calls that follow low-trust content, on new or changed tool manifests, and on memory writes containing instruction-like text. Metrics:

• Prompt-only rules: number of security rules still enforced only in prompts; target zero.
• Secrets in context: credential findings in prompts, tool descriptions or memory per scan.
• Injection test block rate: share of planted injection cases where the harness prevented the action.
• Approval coverage: share of high-impact tool calls that passed through human approval.
• Trace completeness: share of agent runs with a full step-level context log.

Common failure patterns

• Security by system prompt: "never reveal customer data" written in the prompt with no filter in code.
• One service account for retrieval: the agent reads every document the index holds, whatever the user's rights.
• Laundering through summaries: compaction or sub-agent output turns injected text into trusted context.
• Unpinned tool descriptions: a server update changes what the model is told a tool does.
• Keys in the context window: API keys pasted into prompts or tool descriptions for convenience.
• No record of what the model saw: investigators have outputs but not the context that produced them.

Framework mapping

Practitioner checklist

• Document every context source and tool for each agent, with the identity used.
• Label each source with a trust level and carry labels through compaction and sub-agents.
• Enforce authorisation, limits and data rules in harness code, not prompts.
• Keep credentials out of prompts, tool descriptions and memory.
• Run retrieval with the caller's permissions.
• Pin and review tool manifests.
• Require human approval for high-impact actions and restrict actions after low-trust input.
• Log the assembled context per step and test with planted injection cases.

Standards and references

• OWASP GenAI Security Project: Top 10 for LLM Applications 2025
• OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
• MITRE ATLAS: AML.T0080 AI Agent Context Poisoning
• Model Context Protocol: Security Best Practices
• Anthropic Engineering: Effective context engineering for AI agents
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: AI Agent Sandboxing and Code Execution Guide, OWASP Agentic Top 10 ASI01 Guide, Prompt Injection Guide, AI Agent Permission Matrix Template.