Nov 2, 2026 · @disc
AI Agent Harness Security: The Hidden Layer of AI Risk (2026)
The model proposes; the harness disposes. Why the software layer around your LLM is where agentic AI risk lives, and how to secure and govern it under OWASP ASI, ISO 42001 and NIST AI RMF.
Every agentic AI conversation in a boardroom starts with the model. Which one, how smart, how safe, how expensive. That is the wrong place to start.
In September 2026 the Australian Signals Directorate published Agentic AI Harnesses: The layer above the model. Its first key takeaway is one sentence most organizations have not internalized: organizations control the harness, not the LLM.
That sentence reframes the whole problem. You cannot patch a frontier model. You cannot make it stop following instructions hidden in a PDF. But you own, configure and answer for every tool, connector, permission, memory store and log that surrounds it. That surrounding layer is the harness, and your AI agent is only as secure as it is.
This post is the fourth in our agentic AI series. The last one covered the governance operating model: risk tiers, deployment gates, prohibited patterns and where liability lands. This one goes down a layer, to the component that most of those controls actually live in.
What a harness actually is
A harness is everything in an agentic AI system except the model. ASD’s metaphor is the right one: if the LLM is the brain, the harness is the body.
The model takes in context, reasons about it and proposes an action. The harness decides what context the model sees, which tools exist, whether the proposed action is permitted, where it executes, what gets remembered and what gets logged. Then it runs the loop again until the task is done.
Whether you built it or bought it, you have one. Claude Code, Copilot agents, a LangGraph workflow, a customer-service bot wired to your CRM through MCP: each is a harness wrapped around a swappable model.
| Dimension | The LLM | The harness |
| Core job | Predicts the next tokens from what is in front of it | Decides what goes in front of the model and what to do with the output |
| State | Stateless; each call starts fresh | Stateful; persists context, files, memory and progress |
| Actions | Produces tokens only | Executes tools, edits file, runs commands, calls APIs, browses |
| Control | Cannot directly control any action | Permissions, sandboxes, approval gates, hooks, policies |
| Failure mode | Hallucination, wrong answer | Wrong tool, lost memory, unsafe action, context overflow |
| Lifespan | A pluggable part you swap every few months | The durable architecture that outlives any single model |
Adapted from ASD, Agentic AI Harnesses (2026).
Read the Actions and Control rows together. A model on its own cannot delete a file, move money or email a customer list. Only a harness can. Every high-impact agent incident is, by definition, a harness that allowed something.
Why the harness is the real attack surface
The single most important security fact about LLMs is that instructions and data arrive in the same channel. A web page, an email, a code comment or a retrieved contract clause can all be read as a command. That is prompt injection, and ASD states plainly that no fully reliable technical mitigation currently exists inside the model.
The UK NCSC makes the same point from a different angle: prompt injection is not SQL injection. There is no parameterized query for natural language, so you cannot escape your way out of it.
If the flaw cannot be fixed in the model, it has to be contained around it. ASD’s conclusion is direct: mitigations must be applied in the harness, by controlling what an agent can access and what it is permitted to do.
That gives the harness a dual role:
- It is the attack surface. Every tool, connector, MCP server, data source and memory store the harness adds is a new path into the system and a new trust relationship to exploit.
- It is the control plane. It is the only place you can enforce least privilege, approval gates, egress limits and logging deterministically, outside the model’s judgement.
This is also why traditional security tooling under-sees agent risk. In our last post we called it the authorized-adversary problem: an agent exfiltrating data violates no access control. It uses exactly the permissions the harness granted, in a sequence nobody anticipated, because someone else wrote part of its context. The harness is the only component positioned to notice, or to prevent it.
One more implication from ASD worth quoting into your policy: for security purposes, treat a multi-agent system as a single agent. A compromise in one sub-agent propagates through shared context and trust relationships. Your blast radius is the union of every agent’s permission, not the smallest one.
The eleven components are your control surface
ASD breaks the harness into eleven components and calls them the organization’s configuration surface. That framing matters for auditors: most practical controls over an agent are settings in this list. If a control is not configured here, it probably exists only in a prompt.
Below, each component with the way it fails and the control that answers it, mapped to the OWASP Top 10 for Agentic Applications (ASI).
| Component | What it decides | How it fails | Harness control | OWASP ASI |
| User interface | What humans see and can approve | Approval fatigue; users rubber-stamp actions they cannot see | Show the exact action, target and data before approval; one-click stop | ASI09 Human-agent trust exploitation |
| Prompt and policy layer | System instructions, business rules, policy | Rules live only in prose the model may ignore; prompt extraction reveals control design | Version and change-control prompts; enforce critical rules in code, not text | ASI01 Goal hijack |
| Context manager | What information the model sees | Restricted data enters context; important context dropped | Classification-aware retrieval; redact before context, not after output | ASI06 Memory and context poisoning |
| Model interface | Which LLM, with which parameters | Unapproved model or endpoint; data sent to the wrong region or provider | Approved-model allowlist; pinned versions; reassess on model change | ASI04 Supply chain |
| Tool registry | Which tools exist and what they do | Over-broad or vaguely described tools; tool poisoning | Allowlist; narrow single-purpose tools; signed, verified manifests | ASI02 Tool misuse |
| Permission system | What needs approval | Model intent treated as authorization | Policy-based authorization outside the model; human approval for high-impact actions | ASI03 Identity and privilege abuse |
| Execution environment | Where actions run | Unrestricted shell, filesystem or network | Sandboxed, ephemeral, egress-restricted execution | ASI05 Unexpected code execution |
| Connector layer | RAG stores, enterprise systems, MCP servers | Untrusted MCP servers; confused deputy; SSRF | OAuth 2.1 with PKCE; audience-bound tokens; egress allowlists | ASI02, ASI07 Inter-agent comms |
| Memory and session store | What persists between sessions | Stale, sensitive or poisoned entries replayed later | Provenance, TTLs, write authorisation, quarantine, deletion support | ASI06 |
| Audit and observability | What is recorded | Logs the agent can edit; no per-action attribution | Immutable logs held outside the agent’s reach; independent monitoring | ASI10 Rogue agents |
| Update and supply-chain path | How new functionality arrives | Malicious plugin, skill or dependency update | Signed updates; staged rollout; reassessment trigger on every change | ASI04 |
Two things stand out when you lay it out this way. First, of the eleven components, the connector, tool and update paths together account for most of the supply-chain exposure. Second, audit and observability are the component that protects all the others. If the agent can reach its own logs, every other control becomes unverifiable.
Most “model failures” are harness failures
When an agent misbehaves, the reflex is to tweak the prompt. ASD warns against exactly that: investigate the model’s decision and the harness configuration, rather than relying solely on prompt adjustments.
Their example is worth repeating. A model may propose a file deletion. Whether the file is deleted depends entirely on the harness. The proposal is a model event; the deletion is a harness event. Root cause analysis that stops at the model will keep finding the same incident.
ASD’s five risk categories map cleanly onto harness design decisions:
| ASD risk category | What it looks like in practice | Where the harness owns it |
| Privilege | One injected instruction reaches payroll, prod and email at once | Permission system, connector scopes, credentials |
| Design and configuration | Agent ships with a default “allow all tools” profile | Tool registry, execution environment |
| Behavioral | Agent pursues the goal in an unintended way, or is hijacked by poisoned data | Context manager, memory store, approval gates |
| Structural | A bad output from sub-agent A becomes trusted input to sub-agent C | Inter-agent trust, output validation |
| Accountability | Nobody can reconstruct who or what authorized an action | Audit and observability, identity |
Notice that none of the right-hand column is the model. Swapping to a “safer” model changes the likelihood of a bad proposal. It does not change the impact of one. Impact is set by the harness, and impact is what your risk registers, your insurer and your customers care about.
Hardening the harness: ten controls that carry the weight
ASD’s headline is blunt: no harness is inherently secure. Commercial or home-grown, it ships with whatever defaults its builder chose. These ten controls combine ASD’s good-practice list with the operating principles we apply in agent security assessments.
- Separate proposal from execution. Model output must never become privileged execution directly. A deterministic policy check sits between “the model wants to” and “the system did”. This is the single highest-leverage control in agent security.
- Set two dials: least privilege and least agency. Least privilege limits what the agent can touch. Least agency limits what it may do without asking. An agent can be narrowly permissioned and still over-autonomous.
- Run in an organization-controlled, hardened environment. Only the tools and permissions the task needs. No default access to production, sensitive data or open internet. Ephemeral sandboxes for code execution.
- Require human approval for high-impact actions, and make it meaningful. The approval screen must show the actual action, target and data. An approval a human cannot evaluate is a signature, not oversight.
- Validate tool parameters and outputs. Schema-check what goes into tools and what comes back. Treat tool output as untrusted input to the next step.
- Keep context lean and deliberate. Provide only what the task needs. ASD adds a subtle point: when context must shrink, delete stale content rather than summarize it, because summarization rewrites the record and can introduce errors. Persist durable decisions to external files, then start fresh sessions seeded with a concise summary.
- Isolate exploration in sub-agents. Give each sub-agent only the tools, permissions and context for its bounded task. Untrusted web content gets read by a low-privilege sub-agent, not by the agent holding your CRM token.
- Log everything, somewhere the agent cannot reach. Prompts, responses, tool calls, approvals, actions, security events and configuration changes. Protect, retain and independently monitor them.
- Put cost controls on the APIs, and treat them as security telemetry. Agentic sessions consume far more tokens or compute than chat. A spending spike can be a runaway loop, a compromise or a denial-of-wallet attack. Budget caps are a cheap kill switch.
- Maintain a mandatory organizational rules file. Standards, prohibited areas, and build and test commands in a file the harness reads every session. It makes behavior consistent and, critically for audit, reviewable: the rules file is policy-as-configuration you can version, diff and approve.
One ASD line belongs on every architecture review checklist: do not rely on model safety controls instead of harness-enforced controls. Model guardrails are a useful extra layer. They are not a control you can evidence, test on demand or hold a vendor to.
Governing the harness: it belongs in your AI system boundary
ASD makes a strategic point that governance teams should take literally: models get replaced, but the harness is where long-term value, governance and investment accumulate. So govern it as a durable asset, not as plumbing.
The practical consequence is scope. Many AI inventories list “the model” and stop. Under ISO/IEC 42001 your AI system is the whole thing that produces outcomes, which means the harness, its connectors and its memory sit inside the AIMS scope and the risk assessment.
| Framework | Where the harness shows up | Evidence an auditor will ask for |
| ISO/IEC 42001 Clause 4 and 6 | AI system scope; risk assessment and treatment | Inventory listing harness, tools and connectors per agent; risk register entries for each |
| ISO/IEC 42001 Clause 8 and Annex A | Lifecycle, third-party relationships, logging, change management | Change records for prompt, tool, model and connector updates; supplier assessments for harness vendors and MCP servers |
| ISO/IEC 42001 Clause 9 and 10 | Performance evaluation and improvement | Denied-action metrics, red-team findings, corrective actions |
| NIST AI RMF GOVERN / MAP | Accountability; context and dependencies | Named harness owner; mapped trust boundaries and data flows |
| NIST AI RMF MEASURE / MANAGE | Testing; risk response | Prompt-injection and tool-misuse test results; tested kill switch and rollback |
| EU AI Act Art. 14 and 26 | Human oversight; deployer monitoring and log retention | Working intervention and stop controls in the UI; logs retained at least six months for high-risk deployers |
The crosswalk caution from our last post applies doubly here. Do not claim a 42001 control is satisfied because a harness feature exists. “The vendor supports approval gates” is a capability. “Approval gates are configured for these eleven actions, here is the policy version and here are last quarter’s approval logs” is a control.
Reassessment triggers belong in change control, not on the calendar. Re-run the agent’s risk assessment whenever any of these change: the model version, a system prompt or rules file, a tool or its permissions, an MCP server or connector, a memory source, the data classifications in scope, or the harness version itself. Most of those are ordinary engineering commits, which is precisely why annual reviews miss them.
Seven questions your board should ask, and what a good answer looks like
ASD lists seven governance questions for directors. They are good questions. The trouble is that each can be answered with a confident sentence and no evidence. Here is what a credible answer should be able to show.
| Board question | Weak answer | Credible answer shows |
| What outcome is this agent for, and why agentic? | “Productivity.” | A documented use case, a named owner, and why a deterministic workflow was not enough |
| What can it access; is least privilege applied? | “Only what it needs.” | A per-agent list of tools, connectors, scopes and credentials, reviewed on a date |
| What can it do; which actions need approval? | “Humans are in the loop.” | The list of gated actions, the approval policy version, and approval logs |
| How are prompt injection and poisoning mitigated? | “The model has guardrails.” | Harness-level controls plus adversarial test results against this agent |
| Can decisions and actions be monitored and audited? | “We have logs.” | Immutable per-action logs outside the agent’s reach, with a sample reconstruction |
| Is it delivering value within risk tolerance? | “Users like it.” | Value and risk KPIs side by side: denied actions, cost per task, incidents |
| If the harness were compromised, what is the worst outcome? | “Unlikely.” | A written blast-radius analysis and a tested kill switch with its time to stop |
The last question is the one I’d ask first. Worst-case blast radius is a property of the harness configuration, and it can be calculated today. If nobody can produce that number, the agent is not ready for the data it is connected to.
From the practitioner’s chair
When I audited ShareVault’s MCP Governance Standard and produced a v1.1 redline with 27 changes, almost none of them concerned the model. They concerned the connector layer and the permission system: OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity and confused-deputy protections.
In ASD’s vocabulary, every one of those was a harness control. The pattern underneath them all was the same: authority must be bound to a specific action, not held ambiently by a component. An unaudienced token is authority without a destination. An unsigned tool manifest is authority without a definition. A confused deputy is authority without a requester.
The second lesson came from leading ShareVault through ISO 42001 Stage 2 certification on the first attempt. Controls were rarely where programmes struggled; evidence was. The harness is where that evidence is born. If your harness does not emit per-action, attributable, tamper-resistant records, you will have controls you cannot prove.
What to do in the next 90 days
- ☐ Inventory harnesses, not just models. For each agent, record the harness, its version, its tools, connectors, MCP servers and memory stores.
- ☐ Map each agent’s eleven components against the control table above and mark which controls are configured, which are prompt-only and which are absent.
- ☐ Find the proposal-to-execution gap. Identify every path where model output triggers a privileged action without a deterministic policy check, and close it.
- ☐ Move logs out of the agent’s reach and confirm you can reconstruct one real session end to end.
- ☐ Set API budget caps and alert on spend anomalies for every agentic workload.
- ☐ Publish an organisational rules file and put it under change control.
- ☐ Run a prompt-injection test against your highest-privilege agent through a document or email it will actually read.
- ☐ Write the worst-case blast radius for each Tier 3 and Tier 4 agent, and test its kill switch.
ASD’s closing advice is the right rollout posture: start with low-risk use cases, keep humans in oversight, and expand only as controls mature. The model will change next quarter. The harness is what you will still be answering for.
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services organizations secure and govern the layer that actually carries agentic AI risk. Our harness assessments cover agent and connector inventory, component-by-component control review, MCP and tool-permission audits, prompt-injection and tool-misuse testing, blast-radius analysis, and evidence packages mapped to ISO/IEC 42001, NIST AI RMF and EU AI Act Articles 14 and 26.
If you have agents in production and cannot yet answer “what is the worst this harness could do?”, that is the assessment to run now.
“DiscInfoSec” Deura, Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, CA CISSP, CISM · ISO/IEC 42001 and ISO/IEC 27001 Lead Implementer · PECB Authorized Training Partner
Book a call: calendly.com/hd-deurainfosec · Email: info@deurainfosec.com · Phone: (707) 998-5164 · Web: deurainfosec.com
This post is security and governance guidance, not legal advice.
Sources and frameworks
- Australian Signals Directorate / ACSC, Agentic AI Harnesses: The layer above the model, September 2026 (CC BY 4.0)
- Australian Signals Directorate / ACSC, Careful adoption of agentic AI services
- UK National Cyber Security Centre, Prompt injection is not SQL injection (it may be worse)
- OWASP Top 10 for Agentic Applications (ASI01 to ASI10); OWASP Agentic Security Initiative
- ISO/IEC 42001:2023, Clauses 4 to 10 and Annex A
- NIST AI RMF 1.0 (NIST AI 100-1) and NIST AI 600-1 Generative AI Profile
- Regulation (EU) 2024/1689 (EU AI Act), Articles 14 and 26
Primary keyword: AI agent harness security · Secondary: agentic AI governance, prompt injection mitigation, OWASP ASI Top 10, ISO 42001 agents, MCP security, AI risk management
- Someone Is Running Your AI Models Right Now. You’re Paying for It
- Your AI Agent Is Only as Secure as Its Harness: The Hidden Layer of AI Risk
- Your AI Is Live. Your Site Is Your Shop. Who’s Answering for Either?
- Sam Altman Just Issued His Scariest Warning Yet — Fear Tactic or Real Signal?
- Uncover Hidden Subdomains and Expand Your View of the Attack Surface with Subdomains Lookup
https://www.deurainfosec.com/disc-infosec-home/aims-iso42001-ai-governance/
