Agent Harnesses
An agent harness is the framework, SDK, or platform that gives an agent its structure, meaning the layer that turns a language model into a system with memory, tools, and an execution path. Claude Agent SDK and Claude Code, Amazon Bedrock Agents, Microsoft Copilot Studio and Azure AI Foundry Agent Service, the OpenAI Agents SDK, and custom in-house builds are all harnesses. The model does the reasoning, but everything a security team can actually see, configure, or intervene on lives in the harness.
What’s the difference between a model, an agent, and a harness?
A model is the reasoning core, which takes text in and produces text out, with no memory between calls and no ability to act on anything by itself. An agent, in its simplest form, is that reasoning core connected to at least one tool, so the model can now decide to do something as well as say something. A harness is the software that makes that connection possible and keeps it running, which means it manages memory and context between turns, executes the tool calls the model requests, enforces whatever permissions are configured, and decides what the agent is allowed to see and do at each step.
This is a deliberately low bar for “agent”: it covers a single-tool copilot and a multi-agent orchestration under one definition, which matters because most organizations run both, often without a clean line between the two.
The distinction is more than terminology, because control aimed at the model has almost nothing to act on. A model has no persistent state, no tool access of its own, and no execution path to intervene on. Control aimed at the harness has the agent’s actual configuration, context, and execution path to work with, and that is the only place a permission, an approval step, or a policy can actually take effect.
How is a harness different from an agent framework?
The two terms get used interchangeably, and the boundary between them is genuinely blurry in practice, but the distinction is still useful. A framework is a library of building blocks, such as agent objects, tool interfaces and routing primitives, that a team assembles into something that runs. A harness is the assembled, running result, meaning the configured loop that actually calls the model, executes tools, carries state between turns, and applies whatever policies are in place.
In practice, most of what a security team deals with is closer to a harness than a raw framework. Claude Code, Copilot Studio, and Bedrock Agents are all pre-assembled, so a team configures them rather than building them from primitives. A custom build on a framework like LangGraph or CrewAI sits closer to the framework end, where the team building it is responsible for assembling the harness themselves, deciding what state management, tool execution, and interception look like, because none of it ships by default.
Why does it matter which layer governance attaches to?
It matters because one of these layers is durable and the other isn’t.
Models change constantly, so an organization that built its agent controls around a specific model’s behavior, or around a specific provider’s safety properties, has to redo that work every time it switches or adds a model, and most enterprises now run several, which is why governance tied to a model type or a provider ages badly by construction.
The harness is more stable, and more importantly it’s the layer that holds the things governance actually needs: configuration, memory, tool definitions, permissions, and the execution path. Those exist regardless of which model sits inside, so a control attached there survives a model swap in a way that a control attached to the model cannot.
There’s a forward-looking version of this argument too. Agent collaboration is already moving away from static agent-to-agent connections toward ephemeral teams and short-lived messengers that carry work between sessions rather than maintaining persistent links. In that world, a control built around intercepting a stable connection between two known agents has progressively less to attach to, while a control that reads each agent’s own configuration and execution path is unaffected by how transient the collaboration is. This is a bet on where the architecture is heading rather than a description of most current deployments, and it’s worth flagging as such because plenty of enterprise agent estates today are static enough that the distinction hasn’t bitten yet.
Which agent harnesses are most common in the enterprise?
Five cover the large majority of enterprise agent deployment today:
- Anthropic – Claude Agent SDK / Claude Code. Adds a permission system, a system-prompt layer, and 31 documented hook events spanning session lifecycle, tool execution, subagents, and context compaction on top of the raw Messages API loop.
- Amazon Bedrock – Agents Classic and AgentCore. Classic entered maintenance mode in July 2026; AWS is directing new development to AgentCore, which restructures identity, memory, and tool access into separately managed services.
- Microsoft – Copilot Studio and Azure AI Foundry Agent Service. Copilot Studio is a low-code maker tool built around topics and generative orchestration; Foundry is API- and SDK-first. Microsoft Entra Agent ID sits above both as a cross-cutting identity layer.
- OpenAI – Agents SDK. Built on the Responses API, with a published instruction hierarchy that trains the model to weight developer and system instructions over user input and tool content, which is a design-level attempt to make the model itself part of the control system as well as the harness around it.
- Custom / in-house. Built on a framework like LangGraph or CrewAI, or a raw model API loop. There’s no vendor-supplied ceiling and no vendor-supplied floor, so every control point below is possible to build and none of them ship by default.
What should a security team actually look for in a harness?
Two questions are enough to place any harness meaningfully:
Interception depth. Of the moments in an agent’s execution (from the instructions it’s given, through what it retrieves and remembers, to the tool calls it makes and the decisions it takes), how many can a third party actually see into, versus treat as an opaque step between input and output?
Decision-point granularity. Of the points a harness does expose, how many can a third party actually act on, by blocking, modifying or redirecting, before the agent proceeds, versus only observe after the fact?
Every major harness has built real interception mechanisms; the meaningful differences are in where along the agent’s execution those mechanisms sit, and whether a team has to opt into them one tool or one topic at a time, or gets a sensible default.
Common questions
Is an agent harness the same as an agent framework?
Not quite, because a framework is a set of reusable building blocks for constructing an agent, while a harness is the configured, running system that results, meaning the loop that actually calls the model, executes tools, and carries state. A framework can supply part or all of a harness, and a fully assembled platform (Claude Code, Copilot Studio) is itself a harness rather than a framework a team builds from.
Does the model or the harness matter more for security?
They matter for different things. The model determines how well the agent reasons and how resistant it is to being misled by adversarial input. The harness determines what a security team can actually see and intervene on regardless of how well the model reasons. A well-aligned model running in a harness with no interception points is still a system nobody can govern, whereas a well-instrumented harness can enforce a policy even when the model's own judgment is being actively worked against.
Can a custom or in-house agent have a secure harness?
Yes, although none of it comes by default. A team building on a raw framework has to make an explicit decision, for every point in the agent's execution, about whether to instrument it and with what, because there's no vendor documentation acting as a checklist the way there is with a packaged platform. The most common failure mode in custom builds is a control that was never built, rather than one that was configured wrong, because nothing in the framework prompted the team to consider it.
Which harness is the most secure?
That's not a question this kind of comparison can answer honestly, and any answer that ranks vendors on a single security score should be treated with some skepticism. Every major harness ships real, usable control points, and what differs is where those control points sit relative to a security team's actual reach, which depends on the specific deployment as well as the platform. The more useful question for any given team is where its chosen harness's native controls stop, and what has to be added to cover the rest.
