Code Capsules
Company

The AI Harness: How to Run Enterprise AI Agents Securely

Miki von Kotelhodt
Miki von Kotelhodt | CEO at Code Capsules

Last updated: July 2026.

Every engineering team wants agents in production. Every security team wants to know what an agent can reach before it gets there. That gap is where most enterprise AI projects stall.

An AI agent is not a chatbot. It holds credentials, calls tools, reads data and takes actions on your systems. Put one in production without controls and you have handed an autonomous process a set of keys and asked it to be careful. What enterprise AI agents need is a harness: the set of controls that let an agent run where your data already lives, with scoped access, full traceability and a way to stop it. This is the deployment and security playbook for getting there.

The real problem with enterprise AI agents

The demos are easy. Production is where the questions start, and they are the same questions your security review already asks of any service, sharpened by the fact that an agent acts on its own:

  • What can it reach? An agent with a broad API key and open network access is a much larger attack surface than a static service.
  • Where does its data go? Agents that call hosted models can send prompts, and whatever context you attach to them, out of your boundary.
  • What did it actually do? When an agent takes an action, you need a record of what ran, when and on whose behalf.
  • How do you stop it? If an agent misbehaves, you need to pause, roll back or revoke its access without taking down everything around it.

None of these are model problems. They are infrastructure problems. Which is good news, because infrastructure problems have known answers.

What an AI harness is

We use the term AI harness for the layer that makes an agent safe to run in production. A harness does not make an agent smarter. It makes it accountable. Think of it the way you think of a test harness around code: the agent does its work inside a structure that constrains, observes and controls it.

A harness for enterprise AI agents comes down to four pillars.

1. Secrets stay yours

Model keys and API credentials belong in scoped environment secrets, held per workload, never pasted into a notebook or a third-party tool. An agent gets exactly the credentials its job requires and nothing else. Rotate or revoke a key and only the agents that hold it are affected.

2. Agents run where your data already lives

Deploy the agent next to the databases and services it needs, inside the same isolated environment, rather than reaching in from the outside. This is the single biggest reduction in attack surface available to you: there is no new public endpoint for a reviewer to sign off, because the agent is already inside the perimeter, not knocking on it.

3. Behaviour is traceable

Every agent keeps logs, metrics and deploy history. You can show what an agent ran, when it ran, what changed and who changed it. For a security team, "we can produce that record" is the difference between approving a project and blocking it.

4. Containment is built in

Each agent gets its own runtime and its own permissions. If one needs to be paused, rolled back or cut off, you do that to the single agent without touching the rest of your stack. Containment is what turns "an agent went wrong" from an incident into a non-event.

Deploying AI agents in production: the practical choices

Beyond the four pillars, three decisions shape how secure your agent deployment actually is.

Self-hosted models versus hosted APIs. Calling a hosted model is fastest to ship and sends data out of your boundary. Running a self-hosted or open-weight model keeps everything inside. Most enterprises run a mix, and the harness matters more than the choice: either way the credentials, network access and audit trail are what a reviewer cares about.

Network posture. An agent should reach only what it needs. Default to no outbound access, then allow the specific destinations the job requires. An agent that cannot make an arbitrary outbound call cannot exfiltrate to one.

Least privilege, enforced not documented. Scope every credential and every permission to the task. Write it into how the agent is deployed, so the constraint is enforced automatically rather than living in a policy document that drifts out of date.

Get these right and "put an agent in production" stops being a security exception and becomes a normal deployment.

How Code Capsules approaches it

Full disclosure: this is what we build, so read the next paragraph with that in mind.

On Code Capsules, agents run as Capsules in the same governed environment as the rest of your stack, on your own cloud. They get scoped credentials, controlled network access and an audit trail on every action, and each one is isolated with its own runtime and permissions. In other words, the four pillars above are the default rather than something you assemble. If that is the shape of harness your teams need, the enterprise platform page covers it in detail and pricing is public.

The point is bigger than any one platform. Enterprise AI agents are not blocked by model quality any more. They are blocked by the absence of a harness. Build or buy one, and production stops being the place your agents go to wait.

---

*Putting agents in production? See how the AI harness works on Code Capsules or talk to our team .*

Frequently asked questions

What is an AI harness? +
An AI harness is the layer of controls that lets an AI agent run safely in production: scoped credentials, isolation from the rest of your systems, controlled network access and a full audit trail. It does not change what the agent can do, it governs how it does it.
How do you secure AI agents in the enterprise? +
Give each agent only the credentials and permissions its task requires, run it inside an isolated environment next to the data it needs rather than exposing a public endpoint, restrict its outbound network access, and keep logs of every action so behaviour is traceable and reversible.
Should enterprise AI agents use self-hosted or hosted models? +
Both are viable. Hosted APIs are faster to adopt but send data outside your boundary; self-hosted or open-weight models keep data in. The security controls around the agent, credentials, network access and auditing, matter more than the model choice.
How do you secure the AI agent lifecycle? +
Apply the same controls from development through production: scoped secrets, isolated runtimes, least-privilege access enforced in the deployment, and the ability to pause, roll back or revoke any single agent without affecting the rest of your stack.
Why does enterprise AI agent security matter more than for a normal service? +
Because an agent acts autonomously and holds credentials. A misconfigured static service is exposed; a misconfigured agent can take actions on its own. The blast radius is larger, so the containment and auditing have to be stronger.
Miki von Kotelhodt

Miki von Kotelhodt

CEO

Technical Founder helping developers continuously deploy, distribute and scale software on the cloud.