Agent harness privilege is the real boundary in AI security

At a glance

What this is: This is an independent analysis of why the agent harness, not the model, carries the highest privilege in an AI agent stack and where the resulting attack surface concentrates.

Why it matters: It matters because IAM, NHI, and autonomous-identity programmes must govern the component that stores secrets, mediates tools, and writes audit evidence, not only the visible agent.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).

👉 Read Pillar Security's analysis of why the agent harness holds more privilege than the model

Context

Agent harnesses are the fixed control layer that turns a model into an acting system. In practice, that layer carries the credentials, tool registry, context manager, hooks, and session log, which means the real identity boundary often sits outside the model itself and inside the harness that mediates execution.

For identity programmes, that changes the security question from "is the model safe?" to "what can the harness access, who controls those privileges, and how is the trace independently verified?" That lens matters for NHI governance, agentic AI identity, and auditability in human-operated developer environments alike.

Key questions

Q: How should security teams govern agent harnesses that hold secrets and tools?

A: Treat the harness as the protected identity boundary, not the model. Inventory every secret, token, tool permission, and log the harness can access, then apply change control to hooks, tool metadata, and directory-scanned instructions. If the harness can mediate access, it is part of the access-control system and should be governed like one.

Q: Why do agent harnesses create a larger attack surface than the model itself?

A: Because the harness holds the credentials, session state, file-system access, and tool mediation logic that make the agent useful. A compromise at that layer inherits everything the harness can do, which is usually broader than the model's direct capability. The model may generate actions, but the harness executes and records them.

Q: What do security teams get wrong about verify steps in agent workflows?

A: They often assume the agent's own success claim is enough, or that a shared verification layer can be trusted if the model is trusted. In reality, verification must be independent, auditable, and outside the agent's control, because the point is to detect lies and trace manipulation after the fact.

Q: How can organisations reduce risk from tool descriptions and hook logic in agent stacks?

A: By treating them as policy-bearing assets, not documentation. Review and sign tool descriptions, monitor registry drift, restrict hook modification, and test for poisoned instructions through untrusted repositories or MCP updates. If metadata changes can alter runtime behaviour, they belong under access and change governance.

Technical breakdown

Agent harness architecture and privilege boundary

An agent harness is the runtime architecture that wraps a model in a while-loop, tool registry, permissions layer, context manager, hooks, and logs. The model generates intent, but the harness converts that intent into actions and holds the sensitive material needed to do so. In many production stacks, the harness has the browser cookies, OAuth refresh tokens, file-system access, and external API keys that the model never directly sees. That makes the harness the actual privilege boundary, because compromise there exposes everything the agent can do through it.

Practical implication: treat the harness as the protected identity plane and inventory every secret, token, and delegated permission it can reach.

Tool descriptions, hooks, and prompt-injection paths

Modern harnesses often rely on tool descriptions, directory-scanned instruction files, and pre- or post-tool hooks to steer behaviour. Those mechanisms are operationally useful, but they also become control planes for poisoning and redirection if a malicious description, compromised MCP server, or altered registry entry is introduced. Hooks are especially sensitive because they can silently allow, deny, or modify every tool call. The technical failure is not model hallucination alone, but untrusted instruction and mediation layers sitting inside the execution path.

Practical implication: protect tool metadata, hook code, and instruction files with the same change-control and review discipline as production authentication logic.

Trace verification and session log exposure

Agent harnesses often keep append-only logs that capture every tool call, model response, and sometimes secrets that entered context during the session. Because agents can misreport success, the harness also needs an independent verify step that reads the trace separately from the agent output. If the verify layer is absent, compromised, or under the agent's control, the audit trail becomes untrustworthy. If the log itself is stored locally without encryption, it becomes a durable secret store rather than a record of activity.

Practical implication: move verification outside the agent's control and harden session logs as sensitive identity evidence, not harmless telemetry.

Threat narrative

Attacker objective: The attacker aims to take over the harness's delegated control plane so they can execute actions, harvest secrets, and falsify the record of what happened.

1. Entry occurs through poisoned tool descriptions, a malicious AGENTS.md file, a compromised MCP server, or a hook update that alters the harness's control path.
2. Credential access follows because the harness already holds browser cookies, OAuth tokens, API keys, file-system access, and session logs that the model can route through but never needs to see directly.
3. Escalation occurs when the attacker uses the harness's own privilege to influence tool choice, subagent spawning, permission parsing, or trace handling without triggering model-level controls.
4. Impact lands as unauthorized tool execution, secret exposure, manipulated audit evidence, and downstream trust in a false verify step.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• New York Times breach — New York Times source code and credentials exposed via GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The harness, not the model, is the real identity boundary. The article correctly shifts attention from model output to the component that actually mediates credentials, tools, and trace data. That is the control surface where trust, authorization, and auditability collapse if the harness is treated as a mere wrapper. For NHI governance, the practical conclusion is that the most privileged identity in an agent stack is often the orchestration layer, not the LLM itself.

Session log secret retention creates identity blast radius. When every tool call and model response can be persisted locally, the log becomes a durable secret store as well as an audit record. That means exposure is no longer limited to active execution, because a later compromise can reconstruct prior access, credentials, and decision paths. Practitioners should treat trace durability as a governance dimension, not just an observability feature.

Context compaction and self-reporting reveal a verify-step failure mode. The harness is expected to notice when the agent says it succeeded but the trace shows otherwise, yet that assumption only holds if verification is independent and adversarially aware. Once the verify layer shares the same trust boundary as the agent, the control has already failed. The implication is that audit confidence cannot depend on agent self-report or on a verification step the agent can influence.

Tool metadata is a hidden policy layer that needs explicit governance. Descriptions, registry entries, and hook logic decide what the agent believes it may do, which makes them identity-bearing controls even when they are implemented as strings or code snippets. A poisoned metadata update is not just a content issue, it is a privilege-shaping event. Security teams should classify these assets as part of the access control surface, not as documentation.

Agent stacks are creating a new form of delegated privilege debt. The more the harness accumulates secrets, hooks, and subagent permissions, the more the programme depends on implicit trust in layers few IAM teams currently inventory. That is a named governance gap, because the stack can appear functional while its actual authority is concentrated in places no recertification process reviews. Practitioners need to rethink who, or what, is being certified when they review agent access.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 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.
• That governance gap is why the OWASP Agentic AI Top 10 remains a practical reference point for runtime control design and assurance.

What this signals

Identity programme teams should expect harness governance to become a first-class control domain. The security boundary is shifting from model assurance to runtime mediation, which means access reviews, secret inventories, and change control now need to cover hooks, tool registries, and verification layers as governed assets. With 96% of technology professionals already calling AI agents a growing threat, the operational pressure is no longer hypothetical.

Delegated privilege debt is the right concept to track as agent stacks mature. When a harness accumulates credentials, logs, and subagent permissions, the programme inherits a growing trust load that is easy to miss in traditional IAM reporting. Teams that already track machine identity can use that discipline as the baseline, then extend it to agent runtime artefacts and evidence paths.

Trace integrity will matter as much as access provisioning. If the verify step cannot be trusted, every downstream audit inherits a false record of what happened, which creates both compliance risk and incident-response blind spots. Practitioners should align this with zero-trust thinking and the verification patterns in OWASP NHI Top 10.

For practitioners

• Inventory harness-held secrets and delegated tokens Map every credential, refresh token, cookie, API key, and file-system permission the harness can reach, then classify them as production identity assets rather than developer convenience artifacts.
• Separate trace verification from agent control Place the verify step outside the agent execution path, give it independent read access to the trace, and ensure the agent cannot alter the evidence it is being judged against.
• Harden tool metadata and hook change control Subject tool descriptions, registry entries, AGENTS.md files, and pre-tool hooks to formal review, signing, and drift detection because they influence authorization decisions at runtime.
• Encrypt and retain session logs as sensitive evidence Store append-only session logs with encryption and access controls, because they can contain secrets from context and may later be used to reconstruct both abuse and legitimate actions.
• Review subagent spawning as a privilege delegation event Treat any parent-to-subagent handoff as a new trust boundary and recheck permissions, because inconsistent policy enforcement across subagents creates paths around the parent harness.

Key takeaways

• The agent harness is the true privilege boundary in many AI stacks, because it holds the secrets, tools, and logs that the model only routes through.
• Runtime mediation layers such as hooks, tool descriptions, and verification steps create a governance surface that traditional model-only controls do not cover.
• Security teams should govern harness assets like identity infrastructure, with independent verification, hardened logs, and strict control over delegated permissions.

Key terms

• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Trace Verification: Trace verification is the independent checking of what an agent actually did against what it claimed to have done. It matters because agents can report success even when they failed or diverged, so verification must sit outside the agent's control and be auditable in its own right.
• Delegated Privilege Debt: Delegated privilege debt is the buildup of access, tokens, hooks, and inherited permissions in an agent stack that no one actively revalidates. The more layers that can act on behalf of the agent, the more hidden authority accumulates, and the harder it becomes to explain or certify effective access.
• Tool Metadata: Tool metadata is the descriptive and policy-like information that tells an agent what tools exist and how they should be used. In agent systems, it is not just documentation, because poisoned descriptions or registry drift can change runtime decisions and therefore shape effective authorization.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pillar Security: Your Agent Harness Has More Privilege Than Your Agent. Read the original.