Agentic harness security defines the boundary for frontier models

At a glance

What this is: This article argues that the real security boundary for frontier AI models is the deployment harness, not the model itself, because untrusted context and executable tools create the risk.

Why it matters: For IAM and security teams, the lesson is that agentic AI governance must cover permissions, tool execution, and runtime enforcement across NHI, autonomous, and human-controlled workflows.

By the numbers:

• OpenAI's Advanced Cybersecurity Completion Rate evaluation found standard GPT-5.6 Sol completes just 1.5% of exploit-chain requests.
• GPT-5.6 Sol under Daybreak Blue completes only 2.0% of requests because the outer screening layer changes without altering the model's refusal boundaries.
• The specialised GPT-5.6-Cyber model under Daybreak Red achieves a 95.0% completion rate on the same evaluation.

👉 Read Noma Security's analysis of how to safely deploy Fable 5, Mythos 5, and Daybreak

Context

Agentic AI security fails when teams assume the model itself can enforce the boundary between trusted instructions and untrusted content. In practice, the harness around the model decides what context enters the system, what tools are reachable, and what actions can execute, so the primary governance problem is access control, not prompt quality.

That matters for AI agents, code assistants, and security workflows that operate across repositories, secrets, CI/CD systems, and cloud control planes. The article's core point is that higher model capability increases blast radius unless runtime permissions, tool calls, and enforcement sit outside the reasoning loop.

For practitioners, the starting position is typical of most early agent deployments: broad context ingestion first, governance second. That sequence works until the agent is allowed to act on real enterprise systems.

Key questions

Q: What breaks when an AI agent harness is treated as less important than the model?

A: The boundary between trusted instructions and executable action breaks first. If permissions, context filtering, and tool approval are left inside the model loop, prompt injection and reasoning errors can turn into real system changes. Security teams need to treat the harness as the actual control plane and the model as only one component inside it.

Q: Why do step-level authorisation controls matter for agentic AI deployments?

A: They matter because agents do not follow a single human-paced request pattern. A workflow may move from analysis to retrieval to tool execution in one session, and blanket access gives that chain too much reach. Step-level checks force a fresh decision at each sensitive action and reduce the chance that one compromised context becomes a full compromise.

Q: What signs show that an AI deployment has shadow identity and access risk?

A: Look for undocumented MCP servers, untracked tools, unreviewed data paths, and agents that can reach both sensitive data and write-capable systems. Those conditions usually mean the environment has unmanaged identity surface area rather than a single isolated risk. If inventory is incomplete, policy coverage and auditability will also be incomplete.

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Technical breakdown

Why the agent harness, not the model, is the security boundary

A frontier model predicts output from the context it receives, but it does not by itself own tool access, data retrieval, or execution timing. The harness is the production layer that wraps the model with system prompts, APIs, retrieval, and executable actions. Once that layer allows untrusted input and privileged tools to meet in the same runtime, the security question becomes whether permissions are enforced deterministically outside the model's reasoning path. This is why prompt safeguards alone are not enough: they operate inside the same loop that can be manipulated by injected instructions.

Practical implication: Treat the harness as the control plane and place policy enforcement there, not inside prompts.

How step-level authorization changes agentic access control

Traditional session-based access assumes a human or system request begins with a known task and stable privilege needs. Agentic systems break that assumption because they may chain actions across files, tools, and services as they reason. Step-level authorization narrows access at each decision point, while task-scoped just-in-time grants reduce privilege creep across long-running workflows. The useful distinction is between read-only analysis paths and write-capable actions such as deployment or code modification. That separation matters most when the agent can interact with production controls or secrets stores.

Practical implication: Separate read and write paths, and re-check authorization at each high-risk tool call.

What AISPM, red teaming, and AI-DR add to runtime governance

AI security posture management gives inventory and visibility across agents, MCP servers, tools, data stores, and permissions before deployment. Automated red teaming then tests the integrated system, not just the base model, by chaining multi-turn attacks through real ingestion paths such as poisoned binaries or malicious logs. AI-DR extends that work into runtime by inspecting context and tool execution outside the model's reasoning loop. Together, these controls close the gap between what the model can say and what the agent can actually do.

Practical implication: Build a continuous control loop from discovery to red teaming to inline enforcement.

NHI Mgmt Group analysis

The security boundary for agentic AI has moved from the model to the harness. The article shows that system prompts and built-in refusals are insufficient once the model can ingest untrusted content and call external tools. That means the control problem is really about deterministic enforcement around context, permissions, and execution. Practitioners need to govern the runtime wrapper as the real policy boundary.

Step-level authorization is the right abstraction for agentic access, but only because session-based trust no longer holds. Long-running agents can traverse codebases, dependency trees, and toolchains in ways that human-paced access reviews were never designed to observe. The practical shift is from granting broad conversational access to governing each action as a discrete authorization event. That is where least privilege becomes enforceable in agentic workflows.

Shadow AI is now an identity discovery problem as much as a security problem. Unmapped MCP servers, undocumented tools, and unauthorized data paths behave like unmanaged NHIs with active runtime reach. When those assets sit outside inventory, policy cannot be applied consistently and audit trails remain incomplete. The implication is that AI governance starts with continuous discovery of every machine or agent identity that can invoke a tool.

Runtime enforcement must be decoupled from model reasoning to survive prompt injection and destructive mistakes. The article's destructive-action examples show why in-loop safeguards fail when the model itself is manipulated or simply wrong. A control that lives inside the reasoning path can be overridden by the same context it is meant to police. Practitioners should read this as a mandate for out-of-band enforcement architecture across NHI and agentic systems.

Agentic AI governance now sits at the intersection of OWASP-NHI, OWASP agentic AI guidance, and zero trust architecture. Frontier models do not remove identity governance obligations, they expand them across tools, contexts, and autonomous execution paths. The stronger framing is not AI exceptionalism, but identity expansion: every agentic workflow creates another governed identity surface. Security teams should align policy, inventory, and authorization around that expanded surface.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• The OWASP Agentic AI Top 10 is a useful next lens when teams need to turn harness risk into control requirements.

What this signals

Harness governance is becoming the new identity perimeter. As agents gain access to code, secrets, and operational tools, programme owners need a control model that spans discovery, authorization, and runtime enforcement. The practical shift is to treat every tool-connected agent as an identity object with inventory, policy, and audit requirements, not as a mere feature of a larger application.

With 48% of organisations unable to track and audit the data their AI agents access, the compliance gap is already large enough to affect incident response and legal review. That makes agent inventory, tool approval, and log integrity foundational programme work rather than specialised AI security tasks.

Teams that already use the Ultimate Guide to NHIs for lifecycle thinking should extend that discipline to agentic systems, especially where human, NHI, and autonomous access chains meet. The next phase of governance will be less about model selection and more about who or what can act, on which tool, under which policy.

For practitioners

• Map the harness before you map the model Inventory every agent platform, MCP server, retrieval path, tool executor, and connected data store that can influence model behavior or actions.
• Split read-only analysis from write-capable execution Keep triage, summarisation, and threat hunting separate from code commits, deployment actions, and production changes so a single agent cannot move from insight to impact without a new approval step.
• Enforce task-scoped, just-in-time privileges Issue narrowly bounded access for each agent workflow and revoke it at the end of the task so privilege does not persist across sessions or across unrelated tool calls.
• Test the full chain with adversarial red teaming Use multi-turn attack simulations against the integrated harness, including poisoned logs, hostile binaries, and malformed retrieval content, then feed findings into runtime policies before production rollout.
• Move enforcement outside the model context Block dangerous tool calls, verify permissions, and harden runtime policy in infrastructure that the model cannot rewrite, so prompt injection cannot become an execution path.

Key takeaways

• Agentic AI security fails when the harness is left outside the governance model, because the model itself cannot be trusted to enforce its own boundary.
• The article's data shows a material visibility gap, with only 52% able to track and audit AI agent data access and 48% operating with a blind spot.
• Practitioners should focus on discovery, step-level authorization, and out-of-band enforcement if they want to keep agentic deployments within acceptable blast radius.

Key terms

• Agentic Harness: The orchestration layer that lets a model choose tools, execute actions, and repeat a task loop until a goal is met. In practice, it is what turns a model from a responder into an actor, so identity and privilege controls must govern the harness, not just the model.
• Step-Level Authorization: A control pattern that re-evaluates permission at each sensitive decision point instead of granting a broad session-wide allowance. For autonomous or agentic workflows, it narrows the blast radius of a single task and keeps action-by-action accountability intact.
• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

Noma Security's full research covers the operational detail this post intentionally leaves for the source:

• The article's deeper breakdown of Fable 5, Mythos 5, and Daybreak access tiers for different defensive use cases.
• The harness architecture examples showing how MCP servers, retrievers, and automated tool executors fit into a production agent stack.
• The control pillars for AISPM, AI red teaming, and AI-DR, including how they interact in real deployment environments.
• The article's examples of destructive agent failure and the runtime guardrails used to limit blast radius.

👉 Noma Security's full post covers harness controls, agent guardrails, and the deployment tiers in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.