What breaks when an agent harness is not the security boundary?

When the harness is treated as orchestration, not containment

The critical mistake is assuming the harness can do more than coordinate the agent. Once tool invocation, code execution, and network access are delegated to a runtime that the model can still influence, the harness becomes a policy layer, not a hard control. That means the real boundary must sit around execution, credentials, filesystem access, and egress, not just around prompts or system messages.

This matters because agent systems fail at the point where intent crosses into action. A harness can request a tool call, log a decision, or deny a configured path, but it cannot by itself prevent an unsafe plugin, a hostile instruction, or an over-scoped token from being used if those capabilities are already available to the runtime.

Architecturally, the boundary question is about trust placement. If the harness is inside the trust domain, then the model may still shape what it sees, what it requests, and what gets executed downstream. If the harness is outside the trust domain, then every enforcement decision, from allowlists to token scoping, has to be enforced by the execution environment, the authorization layer, and the sandbox, not by the agent workflow alone.

Why prompt control fails when runtime authority stays wide open

Prompt instructions are useful for steering behaviour, but they do not reliably constrain an autonomous system that can call tools or reach external systems. The practical failure mode is over-trust: the task says one thing, the runtime can do another, and the harness has no technical leverage if the agent is already holding broad credentials or direct execution paths.

That is why the safety model breaks at the junction between recommendation and enforcement. If a task-scoped action is not actually translated into task-scoped permission, the agent can still read files, invoke APIs, or chain tools beyond what the request justified. In other words, the harness may express policy, but it does not embody policy unless the runtime enforces it.

Once that gap exists, unsafe tool use becomes a design problem rather than an incident response problem. The same pattern also undermines isolation, because untrusted code or untrusted content can influence state, memory, or downstream actions even when the outer harness believes it is supervising the session.

What a defensible boundary has to control

A defensible boundary is one that can still hold when the model, the prompt, or the surrounding workflow is wrong. That usually means separating planning from execution, constraining each action with explicit authorization, and making the agent operate with the minimum credentials needed for the current task.

In practice, the boundary should cover four things: what the agent may call, what it may see, what it may change, and what it may export. If any of those are left to informal convention, the harness is not the security boundary, it is only the coordination layer.

For agentic systems, that usually pushes control into the runtime stack, not the orchestration layer. The strongest implementations combine action-level authorization, sandboxing, short-lived credentials, and observable execution so that a single compromised prompt does not become a general-purpose system compromise. AI Agent Authorisation Guide explains why least privilege and per-action decisions matter more than friendly instructions. Zero Trust for AI Agents shows how to verify each request rather than trusting the session as a whole. AI Agent Observability, Audit and Incident Response Guide covers the logging and kill-switch side of making that boundary defensible.

Risk and Threat Considerations

When the harness is not the boundary, the main risk is false assurance. Teams believe the control plane is containing the agent, while the agent still has enough runtime authority to misuse tools, invoke unsafe code, or persist through logs, memory, or credentials. That creates a wide blast radius because compromise of the reasoning layer can become compromise of the execution layer.

Failure mechanism: The harness can shape the workflow, but it cannot stop a call chain once the agent has direct access to tools, tokens, or execution contexts outside its control. That is how prompt injection, over-privilege, and untrusted tool outputs turn into real actions instead of just model outputs.

Impact: Unsafe actions may be hard to attribute, difficult to roll back, and broad enough to affect data, systems, or downstream systems beyond the original task. The result is not just bad output, but a weakened security boundary that attackers can exploit for privilege abuse and lateral movement.

Practitioner Guidance

What to prioritise: Treat the agent harness as workflow logic unless you can prove it controls execution, authorization, and isolation. The first question is not whether the agent follows instructions, but whether the runtime can prevent an unwanted tool call even when the model suggests it.

What to verify: Confirm that tool access is brokered through enforceable policy, that credentials are scoped to the task, and that untrusted code runs in a constrained environment with clear egress limits. If any of those checks fail, the boundary is still too soft.

Practitioner takeaway: A harness can coordinate an agent, but only the surrounding control plane can make its actions safe; if enforcement is not external to the model, trust has already leaked past the boundary.

Related resources from NHI Mgmt Group

• Why do AI agent security risks require immediate attention?
• How should security teams handle AI agent visibility?
• How should security teams monitor AI agent activity without disrupting developers?
• What breaks when the agent harness, not the model, is treated as the boundary?