Engineering a security harness for AI coding agents

Imagine hiring a brilliant security engineer. They’re fast, capable, and eager to help. On day one, you give them access to your source code, GitHub, application security platform, and communication systems. Then you ask them to find and fix the vulnerabilities that matter most.

This sounds great but comes with a few problems: they don’t know your architecture. They don’t know your risk tolerance, your policies, your approval process, or which systems and files must never be changed.

Most organizations would never onboard a human security engineer this way. But it’s surprisingly close to how many teams deploy AI agents today.

The model may be capable of reasoning, using tools, and taking action. But intelligence alone isn’t enough for consequential security work. The real engineering challenge is the system around the model: how it receives context, what it can access, when it can act, what it must prove, and where it must stop. 

That distinction becomes more important as agents perform more and more of the day-to-day coding work.

In this post, I’ll walk through seven questions for engineering a security harness for AI coding agents. The first four are architectural: how to define the agent’s job, provide the right security context, constrain its authority, and enforce transitions between reasoning and action. The final three are operational: how to evaluate the agent, how to contain failures, and how to manage change over time.

Together, they provide a practical framework for building—or evaluating—AI security agents that can do consequential work without treating the model itself as the control plane.

The model is not the control plane

An agent security harness is the system around a model that supplies trusted context, constrains capabilities, governs workflow, and verifies results. At the center is the probabilistic part: the model reasons, synthesizes information, and generates an answer or plan. Around it sits the engineered part: task scope, trusted evidence, tools and permissions, workflow gates, approval state, evaluation, containment, and change control. 

That separation matters because prompts are not security controls. You can tell an agent not to modify production code. You can tell it to ask before opening a pull request. You can tell it never to make assumptions when evidence is missing.

Those instructions are useful. But for higher-risk actions, we need to go beyond prompts and implement hard controls. 

The agent wasn’t merely told not to. It could not proceed until the required conditions were met.

Building that kind of system requires thinking about the harness in two parts: how you architect the agent’s path to action, and how you operate the resulting system safely over time.

Architecting the security harness

Before an agent performs consequential security work, the harness needs to answer four basic questions: 

1. What job is the agent doing? 
2. What evidence does it need? 
3. What authority does it have? 
4. What must be true before it can move forward?

Those questions define the path from probabilistic reasoning to controlled action.

1. What job are we assigning the agent?

“Do security and don’t make mistakes” is not a useful task definition.

An agent might understand a problem by explaining a vulnerability or summarizing security posture. It might decide by selecting the best remediation or prioritizing a finding. Or it might act by editing code, changing configuration, or creating a pull request.

Those are very different jobs, with very different consequences.

As the agent moves from understanding to deciding to acting, the harness needs to become more explicit about the contract around the task.

At minimum, that contract should identify:

• the target
• the evidence required to complete the job
• the conditions under which the agent must stop
• the authority the agent has to take action

If those things are vague, the harness has no reliable way to determine whether an agent run is acceptable. fileciteturn0file0L119-L142

2. What must the agent know?

The tempting answer is: give the agent everything. Everything in the repository. Everything in the security platform. Every finding, dependency, ticket, commit, and policy you can fit into the context window.

More context does not necessarily mean better context. For security work, we want the smallest sufficient set of authoritative evidence for the task at hand.

A remediation agent evaluating a dependency upgrade might need the exact project and source revision, current dependency version, available upgrade, known findings, reachability information, dependency conflicts, and expected changes to the dependency graph.

It probably does not need a giant dump of every security fact we know about the organization.

The pattern we use in Endor Labs Agent Kit is deliberately narrower:

Resolve scope → retrieve evidence → reason → record gaps.

Deterministic systems establish facts such as versions, findings, reachability, and upgrade impact. The model does what it is good at: synthesizing those facts, weighing tradeoffs, explaining ambiguity, and planning what should happen next.

The harness owns the path between them. It decides which evidence is required, which source is authoritative, and when the agent has enough information to proceed.

And when evidence is unavailable or contradictory, that absence should remain visible.

Missing evidence is a result, not permission to guess. 

This approach is not only about control. Evidence architecture can dramatically change how an agent uses the model.

In one Endor Labs benchmark, we compared agents that received deterministic security evidence with agents that had to reconstruct security posture themselves through reconnaissance and tool loops.

Across 34 prompts, 13 scopes, and 884 responses using the same model and step limits, the evidence-equipped approach used 91.7% fewer tokens: 6.6 million compared with 79.5 million.

It was also faster and required fewer model and tool-loop calls.

That benchmark measures execution economics, not correctness, and it excludes deterministic upstream computation from the marginal per-question cost. The exact gains will vary with the task, evidence requirements, model, and environment.

But the architectural lesson is important: if the model has to rediscover facts your security systems already know, you pay for that uncertainty over and over again. fileciteturn0file0L187-L211

3. What is the agent allowed to do?

Agent permissions are often discussed as though there are two states: read-only and autonomous.

In practice, there are several meaningful levels of authority:

Read → Recommend → Prepare → Publish → Enforce

An agent may be allowed to inspect evidence without making recommendations. It may be allowed to recommend a remediation without changing a file. It may be allowed to prepare a local patch but not publish it.

Publishing introduces another boundary: pushing a branch, opening a pull request, creating a ticket, or sending a comment changes the external system.

Enforcement goes further still: merging code, modifying policy, approving an exception, or otherwise making a decision take effect.

The critical principle is that authorization should not silently cascade from one level to the next.

Approving a patch does not imply permission to push it.

Permission to open a pull request does not imply permission to merge it.

Permission to remediate one vulnerability does not imply permission to change the organization's security policy.

Each transition deserves its own evidence and authority requirements.

4. What must the agent prove before proceeding?

This is where harness design moves beyond instructions. Think about controls in three layers.

1. Instruction guides. It tells the model what evidence to use, what process to follow, and when approval should be requested.
2. Validation rejects. It checks whether required evidence, provenance, risk decisions, validation results, or approval state are missing.
3. Enforcement withholds. The runtime simply does not expose or execute consequential capabilities until the required conditions have been satisfied.

Not every part of an agent run needs to be deterministic. In fact, expecting identical reasoning or prose from every run misses the point of using a model in the first place.

What can be made deterministic, however, are the conditions for an acceptable run: required schemas, evidence prerequisites, approval gates, tool permissions, budgets, stop conditions, and validation requirements.

Harness engineering does not require every run to be identical. It requires every acceptable run to satisfy the same rules.

What a controlled agentic workflow looks like in practice

Consider an agent tasked with remediating a vulnerable open source dependency. A controlled workflow might look something like this:

First, the harness resolves the exact project and revision. Then it retrieves the minimum evidence required to evaluate upgrade candidates. The agent selects an upgrade and assesses its risk. It presents a plan.

And then it stops.

Only after receiving explicit edit approval does it modify the file. It validates the resulting dependency resolution, tests, security-finding delta, and working-tree scope.

Then it stops again.

Preparing and validating a fix did not grant authority to publish the fix. Opening the pull request is a separate transition with a separate approval boundary. 

That distinction is easy to lose when we think of agents as single prompts or uninterrupted chains of tool calls. In reality, consequential workflows should behave more like state machines. 

They may also need loops. Missing evidence could trigger a targeted retry. Failed validation could send the agent through a bounded repair cycle. But those loops should have budgets, retry ceilings, and explicit stop conditions.

A loop can recover. It cannot skip a gate.

We demonstrated this with a deliberately simple dependency remediation: upgrading Jinja2 from 3.1.1 to 3.1.6 in a single manifest. The interesting part was whether the system could establish the evidence for the change, stop for approval, perform and validate the scoped edit, and then stop again before publication.

The success condition wasn't simply, “the agent found the upgrade.” It was that the agent stopped at the right boundaries. 

Operating the security harness

A well-designed agent can still produce a bad result, encounter adversarial input, fail mid-run, or behave differently after a model or tool update. That means safe operation requires its own set of controls.

5. How do we know it works, and can we challenge it?

Once an agent is operating, model accuracy alone is not a sufficient evaluation framework.

We need to evaluate at three levels.

1. Process: Did the agent follow the required evidence path, permissions, and approval gates?
2. Result: Was the answer or remediation correct, complete, and actionable?
3. Outcome: Did the change actually reduce risk without introducing regressions?

There is another requirement that becomes especially important as agents make more consequential decisions: contestability.

A human reviewer should be able to see the evidence behind the recommendation, understand the assumptions the agent made, identify missing information, challenge its conclusion, reject it, or rerun the task with corrected context.

A human clicking “approve” without enough information to disagree is not meaningful human oversight.

6. What happens when the agent is wrong, attacked, or interrupted?

Agents will fail. Models will make mistakes. Tools will return unexpected results. Repositories will contain untrusted text. Network calls will time out. Runs will be interrupted halfway through.

The harness needs an answer for those conditions before the agent is trusted with consequential actions.

That means failing closed when required proof is absent. It means treating repository contents and tool output as data, not authority. It means limiting credentials, tools, and blast radius.

It also means designing workflows so interruptions do not leave systems in ambiguous states. Checkpoint state where appropriate and make retries idempotent so repeating an operation does not accidentally duplicate or compound its effects.

One principle is especially important in systems where an LLM can encounter instructions from many sources: Untrusted text never becomes authority. 

7. How does the agent change safely, and who owns it?

An agent is not finished when the first version works.

The prompts will change. Models will change. Tools will change. Security policies will change. Evidence schemas and integrations will evolve.

Those changes can alter agent behavior even when the high-level job appears unchanged.

So the task contract and execution context need to be versioned. New versions should be tested deterministically and adversarially. Releases need rollback paths. Agents should be monitored in operation, and obsolete versions should eventually be retired without destroying their audit history.

Ownership also needs to be explicit.

Who owns the agent itself? Who owns the platform it runs on? Who owns the security policy? Who owns the affected application? Who responds when something goes wrong?

AI agents blur traditional software and organizational boundaries. They don't eliminate the need for ownership. They make it more important. fileciteturn0file0L493-L509

Seven questions for building a controlled AI security agent

The examples above use dependency remediation and AI SAST, but the framework is not specific to either one. The evidence will change from one security task to another. The controls around that evidence should remain consistent.

For an SCA upgrade, the harness may need dependency versions, finding deltas, upgrade risk, and conflict analysis. For an AI SAST finding, the agent may instead need the affected code path, exploit reproduction, data and control flow, and remediation guidance.

What we’ve shown is a common control framework across both the architecture and operation of the agent:

1. What job are we assigning it? Define the task and its boundaries.
2. What must it know? Engineer the smallest sufficient path to trusted evidence.
3. What is it allowed to do? Separate reading, recommending, preparing, publishing, and enforcing.
4. What must it prove before proceeding? Make evidence, validation, and approval prerequisites to consequential actions.
5. How do we know it works—and can we challenge it? Evaluate the process, result, and outcome while making decisions contestable.
6. What happens when it is wrong, attacked, or interrupted? Fail closed and contain the blast radius.
7. How does it change safely, and who owns it? Version, test, monitor, and assign explicit ownership.

The specific evidence contract changes with the security job. The questions governing the harness do not

Engineer the system, not just the model

The capabilities of frontier models will continue to improve. Agents will get better at reasoning, navigating codebases, using tools, and executing increasingly complex workflows.

But a more capable model is still not a controlled system.Before we trust agents with consequential security work, we need to define the job, engineer the evidence path, and enforce the transitions.

The model can remain probabilistic. The guarantees around it cannot.