Two AI products can feel completely different while running the exact same underlying model. The same model can be a basic back-and-forth chatbot in one place and, dropped into a developer tool with access to files and a terminal, work autonomously for hours on a software task in another.

That gap is worth sitting with, because most enterprise AI security programs are built on the assumption that it does not exist. Vendor reviews ask which model. Risk registers list which model. Approval workflows gate which model.

A recent IBM Technology explainer by Martin Keen draws the distinction that makes the gap legible: AI model versus agentic harness. It is a capability framing, not a security one. But follow it one step further and it reorganizes where enterprise AI risk actually sits — and it is not where most teams are looking.

AI model versus agentic harness — on the left, a brain sealed in a glass jar labelled isolated capability; on the right, the same brain connected through the harness to tools, memory, instruction files, and a plan-act-verify-observe agentic loop, with the external attack surface it opens marked by prompt injection, data exfiltration, and unauthorized action warnings

The brain in a jar

Start with the model itself, because it is the simpler half. When we say "model," we mean the actual artificial neural network. And what a model cannot do on its own is reach out into the world. It cannot open a file. It cannot run code. It cannot browse the web natively.

Keen's image for this is exact: a model on its own is a brain in a jar. Capable, but trapped.

That word — trapped — is the part security teams should notice. An isolated model has no blast radius. It cannot exfiltrate your customer database, because it cannot reach your customer database. It cannot push a bad commit, because it cannot reach your repository. Whatever risk it carries is confined to the text it produces.

There is a second observation that sharpens the point. Benchmark gaps between the top labs have narrowed to within a few points of each other on most evals. So when one AI product clearly outperforms another, the brain usually is not the explanation. It is what is wrapped around the brain.

That wrapping has a name: the agentic harness. And the arithmetic that follows is straightforward:

AI agent = AI model + agentic harness

The tools the model uses, the way it remembers things, the loop it keeps running, the rules about what it is allowed to do — all of that lives in the harness, not the model.

What is inside the harness

The harness has three components. Each one is a capability story in the original framing. Each one is also, read from the other direction, an attack surface.

Tools — the blast radius

Tools are how the model does things out in the world: read and write files, run code (sometimes in a sandbox), fetch information from the internet, and increasingly computer use — moving a cursor and operating any software the way a person would.

Many of these are built into the harness directly. For anything else already on the machine, a harness typically hands the model the command line, so it can run whatever software is installed — the same way a developer would. And for external services that do not live on the machine, a corporate database or a third-party SaaS app, there is MCP (Model Context Protocol): build a tool once, and it plugs into any harness that supports it without being rebuilt.

Now read that paragraph as a security assessment. Filesystem access, arbitrary code execution, outbound network calls, full desktop control, shell access to everything already installed, and a standardized connector into your internal systems — none of which is a property of the model you approved. The model cannot leak your database. The MCP tool wired into it absolutely can.

MCP's portability cuts both ways, too. The property that makes a tool valuable — write once, works in every harness — means a connector approved for one context travels to every other context by default.

Memory — the persistence and injection surface

Models have a fixed context window, essentially working memory, and it is wiped clean when the conversation ends. The harness is what makes anything persist.

It does this three ways. Instruction files, like an agents.md sitting in a project folder, get loaded into the model's context at the start of every session — this is how the model learns the codebase's conventions and which libraries to use. Compaction kicks in when the context window fills: the harness summarizes what happened earlier, keeping the important parts and pruning redundant tool output. And rather than dumping an entire codebase into context, the harness lets the model search — grep-style text search, semantic search, code indexes — pulling in only the pieces it needs.

Each of these has a security shadow that the capability framing does not need to mention:

An instruction file loaded into every session is one of the highest-leverage prompt injection targets in the building. Whoever can write to that file steers every future run, and it usually lives in a repo with ordinary commit permissions rather than anything resembling policy change control.
Compaction means the record of what the model actually saw is lossy by design. If your audit story is "we log the conversation," compaction is quietly deciding which parts of it survive.
Search pulls in whatever it matches. A grep that reaches a .env file, a credentials fixture, or a customer record does not know it should have stopped — it just returns the hit and the harness feeds it forward.

The agentic loop — the multiplier

This is where the harness and the model work together. The model decides the next step toward the goal — the plan. The harness performs the action. The action produces results. The model observes those results, and the loop goes around again. Sometimes for seconds. Sometimes for hours.

Modern harnesses also run verification continuously through the loop: the model runs tests as it goes, takes screenshots of what it has built, sometimes spins up a separate model to act as a reviewer. A model that double-checks itself can run much longer without going off the rails.

Verification is genuinely the good news here, and it deserves to be named as such — self-checking is what makes long autonomous runs viable at all. But note what it is: a quality control, aimed at correctness. It does not ask whether the action was permitted, whether the data should have left the building, or whether anyone would be able to reconstruct the decision later. An agent can verify its way to a perfectly correct action that your policy never authorized.

And the loop is a multiplier on everything above it. One human prompt becomes hundreds of autonomous tool calls over hours. Authorization granted once at the top of the loop is being spent, unexamined, at hour three — against a plan the model wrote after the human stopped watching.

Why this reorganizes the risk picture

Once the model and the harness are separate objects, several things that have been confusing about enterprise AI get easier to explain.

Most recent capability gains came from the harness, not the model. Better tools, better memory handling, smarter loops with verification. Models improved too, with every version — but the harness is where the compounding happened. Security programs pointed entirely at model selection have been auditing the half that changed least.

"Is AI good at this?" is an underspecified question. Is AI good at writing code? At customer support? The useful version names both halves: which model, and which harness. As Keen puts it, a model can be brilliant in one harness and get stuck in another.

The security version of that question is the one worth adopting internally. Not "have we approved this model?" but "what is this model wired into, and who decided that?" The same approved model, in two different harnesses, is two different risk profiles that share nothing but a name on the invoice.

This is also what most shadow AI actually turns out to be. Not an unapproved model — the model is usually one you have already blessed. It is an unapproved harness: an agent someone assembled with tool access, an MCP connector added to a local setup, an instruction file nobody reviewed. Your inventory says the model is sanctioned and the inventory is telling the truth. It is just answering a question that stopped being the important one.

And the line between the two is fluid. Capabilities that used to live entirely in the harness — long-horizon planning, self-verification — are starting to be trained into models directly. Things that used to be model behavior, like consistency over a long task, are increasingly shaped by harness conventions and project files. Neither half is a stable place to attach a control.

Which is exactly why controls that live inside the model, or inside the harness, keep sliding out from under you. The durable place to attach them is the boundary — the traffic between them.

Where security actually attaches

Every one of the harness capabilities above crosses an observable boundary. That is the useful thing about this decomposition: it tells you where to stand.

Model traffic crosses the gateway. Every prompt the harness assembles — the instruction files it loaded, the search results it pulled in, the compacted history it kept — leaves as an outbound request. That is the point where you can see what the harness actually sent, redact what should not leave, and write a record that compaction cannot erase. This is the same visibility gap we walked through in AI Coding Agent Security: the payload is the evidence, and it exists for exactly one moment.

Tool calls cross the MCP layer. File access, code execution, database queries, third-party actions. Brokering them at an MCP layer with scoped, short-lived credentials and per-call authorization is what turns "the agent has access" into "the agent was authorized for this call, at this moment, with these arguments." MCP You Can Trust covers what that layer has to get right.

The loop needs continuous authorization, not a starting gun. An agent running for hours re-derives its own plan repeatedly. Point-in-time approval does not survive that. This is the Adaptive tier of the Agentic AI Maturity Model — continuous validation, risk-based escalation, revocation that lands mid-run rather than at the next login.

SecuriX sits at both boundaries: the Enterprise AI Gateway in front of model traffic, and a brokered MCP layer in front of tool calls. Not because the harness is untrustworthy, but because it is where the capability lives — and controls belong where the capability is, not where the brand name is.

The takeaway

The brain keeps getting smarter. That much is not in doubt.

But it is not just the brain. It is also the jar — and the jar is the part with your filesystem in it, your database connector, your credentials, and a loop that will keep running long after the person who started it has closed the laptop.

If your AI risk assessment has a row for the model and no row for the harness, it is describing about ten percent of the system.

🎥 A Recommended Watch

This post builds on Martin Keen's explainer for IBM Technology, which lays out the model-versus-harness distinction cleanly and is well worth the eight minutes: AI Model vs Agentic Harness: What Actually Drives AI.

🚀 Call for Design Partners

We are working with a small group of Design Partners deploying the SecuriX security layer across both the LLM gateway and MCP server tiers.

If you are putting agents into production and want the harness governed as carefully as the model was approved, we want to talk. Partners get early access to the SDK and portals, white-glove onboarding, and direct influence on the roadmap.

Reach out to us or send us a DM, and we will get you set up.

This post is part of SecuriX's mission to make enterprise AI secure, compliant, and trustworthy.

AI Model vs Agentic Harness