Containment harness

A containment harness is a restricted deployment wrapper that limits what an AI model can do if it is prompted into risky behaviour. It can include sandboxing, policy enforcement, separate execution paths, and strict logging to prevent unbounded actions.

Expanded Definition

A containment harness is not the model itself, but the controlled environment around it: a deployment wrapper that constrains execution, tool access, data movement, and outbound effects when an AI system behaves unpredictably. In practice, it sits between the model and the systems it could otherwise influence, so risky prompts do not automatically translate into risky actions. For NHIMG, the important distinction is that containment is operational and architectural, while model safety is behavioural and statistical. A harness may route requests through approval gates, isolate file and network access, enforce policy checks, and record every significant action for auditability. That makes it closely related to security engineering concerns discussed in NIST Cybersecurity Framework 2.0, even though no single standards body has yet formalised one universal definition for the term. Usage in the industry is still evolving, especially where agentic AI can call tools or trigger workflows.

The most common misapplication is treating prompt filtering as a containment harness, which occurs when organisations block unsafe text but leave execution paths, credentials, and network reach unchanged.

Examples and Use Cases

Implementing a containment harness rigorously often introduces latency and operational friction, requiring organisations to weigh reduced blast radius against slower workflows and more complex approvals.

• An internal coding assistant runs in a sandbox with no direct internet access, so generated commands cannot reach external endpoints without review.
• An agentic workflow uses a separate execution path for email or ticketing actions, with policy checks before any message is sent or ticket is closed.
• A research model can read approved documents but cannot write to production databases, preventing accidental or adversarial data modification.
• A finance automation agent is forced through an approval queue for payment instructions, even when the model appears confident in its recommendation.
• All model decisions, tool calls, and policy denials are logged so investigators can reconstruct what happened after a suspicious output or unsafe action.

These patterns align with the broader defensive logic behind NIST Cybersecurity Framework 2.0, where control, visibility, and response are essential to reducing impact. The term is especially relevant where an LLM is connected to tools, because the safety problem is no longer just what the model says, but what the surrounding system lets it do.

Why It Matters for Security Teams

Security teams care about containment harnesses because they create a practical boundary between model output and enterprise harm. Without that boundary, a compromised prompt, poisoned context, or overconfident agent can create unauthorized access, data leakage, workflow abuse, or destructive side effects. This is particularly important for non-human identities and agentic AI, where credentials, API keys, and delegated permissions can be exposed to actions the business never intended to automate. A containment harness does not eliminate model risk, but it reduces the chance that one bad interaction becomes a system-wide incident. It also improves forensic visibility, since strict logging and separated execution paths make it easier to determine whether the failure was caused by the model, the prompt, the tool chain, or the policy layer. That distinction matters when teams are trying to restore trust after an incident and decide whether to disable an agent, revoke secrets, or tighten access policy. Organisationally, the need for a containment harness often becomes clear only after an agent has already attempted an unsafe action, at which point the control becomes operationally unavoidable.

For teams building AI governance around access control and execution boundaries, the NIST Cybersecurity Framework 2.0 provides a useful anchor for response, monitoring, and protective control design.

Related resources from NHI Mgmt Group

• What is the difference between preventive controls and runtime containment?
• What is the difference between MFA and post-login containment?
• What is the difference between least privilege and session containment for AI agents?
• When should organisations add containment controls to AI agent deployments?