Agent Harnesses
An agent harness is the framework, SDK, or platform that gives an agent its structure — 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 reasons. 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 — it 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: the model can now decide to do something, not just say something. A harness is the software that makes that connection possible and keeps it running — 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 reason this distinction is more than terminology: 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 — which 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 useful: a framework is a library of building blocks — agent objects, tool interfaces, routing primitives — that a team assembles into something that runs. A harness is the assembled, running result: 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 — 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: 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.
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 — a design-level attempt to make the model itself part of the control system, not just the harness around it.
- Custom / in-house. Built on a framework like LangGraph or CrewAI, or a raw model API loop. No vendor-supplied ceiling and no vendor-supplied floor — 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, 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 — block, modify, redirect — 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. A framework is a set of reusable building blocks for constructing an agent; a harness is the configured, running system that results — 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, not 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; 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, but nothing about it is 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 — 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 isn't a control that was configured wrong; it's a control that was never built, 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 is a function of the specific deployment, not just 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.
