AI Coding Agents Need More Than Guardrails: Why Security Harnesses Matter

AI Coding Agents Need More Than Guardrails: Why Security Harnesses Matter

AI coding agents are moving beyond simple code suggestions. They can inspect repositories, analyze security findings, modify files, use development tools and participate in software workflows.

That creates a new security challenge.

The question is no longer only whether an AI model can produce useful code. It is whether the system surrounding that model can control what the agent sees, what it is allowed to do, when it must stop and how its work is verified.

In a September 23, 2026 article, Endor Labs' Andrew Stiefel describes this surrounding system as a security harness for AI coding agents. The article presents seven questions that security and engineering teams should consider before allowing agents to perform consequential security work.

The central idea is straightforward: a capable AI model is not automatically a controlled system.

The Model Is Not the Control Plane

An AI model is designed to reason, synthesize information and generate responses or plans. But security controls require something more deterministic.

According to Endor Labs, a security harness sits around the model and provides:

• Defined task scope

• Trusted security evidence

• Tool and permission controls

• Workflow gates

• Approval states

• Validation

• Evaluation

• Failure containment

• Change management

This distinction matters because prompts alone should not be treated as security controls.

For example, an organization might instruct an agent not to modify production code or to request approval before creating a pull request. Those instructions can guide the model, but higher-risk actions require controls that technically prevent the action until the necessary conditions are met.

In simple terms:

A prompt can tell an agent what it should do. A security harness determines what it is actually allowed to do.

The Seven Questions Behind a Controlled AI Security Agent

Endor Labs divides the framework into four architectural questions and three operational questions.

Together, they describe how organizations can move from an AI agent that simply has capabilities to an agent operating inside a defined security process.

1. What Job Is the Agent Actually Doing?

The first step is defining the agent's responsibility.

A broad instruction such as "do security and don't make mistakes" does not establish a meaningful security boundary.

An agent could be asked to:

• Explain a vulnerability

• Summarize security posture

• Prioritize a security finding

• Recommend remediation

• Prepare a code change

• Modify source code

• Change configuration

• Create a pull request

These activities have different levels of consequence.

Endor Labs recommends defining a task contract that identifies the target, required evidence, stopping conditions and permitted authority. Without those boundaries, it becomes difficult to determine whether an agent execution was acceptable.

Why this matters

An AI agent that only explains a vulnerability does not need the same authority as an agent that can modify application code.

The security harness therefore needs to understand not just what the model is capable of, but what task it has been authorized to perform.

2. What Does the Agent Need to Know?

More context does not automatically produce better security decisions.

Giving an agent an entire repository, every security finding, all tickets and every available policy may introduce unnecessary information instead of improving its reasoning.

Endor Labs recommends providing the smallest sufficient set of authoritative evidence for the specific task.

For a dependency remediation task, this could include information such as:

• The exact project and source revision

• Current dependency version

• Available upgrade

• Known security findings

• Reachability information

• Dependency conflicts

• Expected dependency graph changes

The article describes a narrower workflow:

Resolve scope → Retrieve evidence → Reason → Record gaps

Deterministic systems establish facts, while the model interprets those facts, weighs tradeoffs and develops a plan.

An important principle follows:

Missing evidence should remain visible. It should not become permission for the model to guess.

Endor Labs' benchmark

Endor Labs also reports a benchmark comparing agents that received deterministic security evidence with agents that had to reconstruct security posture through reconnaissance and tool loops.

According to the company, the benchmark covered 34 prompts, 13 scopes and 884 responses using the same model and step limits. The evidence-equipped approach used 91.7% fewer tokens, with 6.6 million tokens compared with 79.5 million. Endor Labs notes that this benchmark measured execution economics rather than correctness, and that the results can vary depending on the task, evidence requirements, model and environment.

For enterprises, the broader lesson is that feeding agents authoritative evidence may reduce the amount of work they need to spend rediscovering information that security systems already possess.

3. What Is the Agent Allowed to Do?

AI agent permissions should not necessarily be treated as a simple choice between "read-only" and "fully autonomous."

Endor Labs proposes five levels:

Read → Recommend → Prepare → Publish → Enforce

Each represents a different level of authority.

Read

The agent can inspect information without making recommendations or changes.

Recommend

The agent can analyze evidence and suggest a remediation.

Prepare

The agent can prepare a patch or change without necessarily publishing it.

Publish

The agent can push a branch, open a pull request, create a ticket or send a comment that changes an external system.

Enforce

The agent can perform actions such as merging code, changing policy or making an approved decision take effect.

The key principle is that authorization should not silently cascade.

Permission to prepare a patch does not automatically mean permission to publish it.

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

This creates clear security boundaries between different stages of an agent workflow.

4. What Must the Agent Prove Before Proceeding?

This is where the security harness moves beyond instructions.

Endor Labs describes three layers of control:

1. Instruction guides
   Tell the model what evidence to use and what process to follow.

2. Validation rejects
   Check whether required evidence, provenance, risk decisions, validation results or approvals are missing.

3. Enforcement withholds
   Prevent consequential capabilities from being exposed or executed until required conditions are satisfied.

Not every part of an AI agent's reasoning needs to be deterministic.

The important point is that the conditions for an acceptable action can be deterministic.

These conditions can include:

• Required evidence

• Approval gates

• Tool permissions

• Validation requirements

• Budgets

• Stop conditions

• Required data structures

The objective is not to make every AI response identical. It is to make sure that every acceptable execution satisfies the same security rules.

What a Controlled AI Coding Workflow Looks Like

Endor Labs uses dependency remediation as an example.

Imagine an AI agent has been asked to address a vulnerable open source dependency.

A controlled workflow could follow these stages:

1. Resolve the project

The harness identifies the exact project and source revision.

2. Retrieve evidence

The system collects the minimum information required to assess available upgrade options.

3. Reason and plan

The agent evaluates the available upgrade and assesses the relevant risks.

4. Stop for approval

The agent presents its plan rather than immediately changing the code.

5. Make the approved edit

Only after explicit approval does the agent modify the relevant file.

6. Validate

The system checks dependency resolution, tests, security-finding changes and the scope of the working-tree modification.

7. Stop again

The agent does not automatically receive permission to publish the change.

8. Separate publication

Creating a pull request or otherwise publishing the change becomes another authorization boundary.

This makes the workflow resemble a state machine rather than one uninterrupted chain of AI tool calls.

A failed validation can trigger a bounded repair loop. Missing evidence can trigger a targeted retry.

But the loop should not be able to bypass an approval gate.

As Endor Labs puts it conceptually, a loop can recover, but it cannot skip a gate.

The article illustrates this approach using a Jinja2 dependency upgrade from version 3.1.1 to 3.1.6 in a single manifest. The important aspect was not simply identifying the upgrade. It was whether the system could gather evidence, stop for approval, perform and validate the edit, and stop again before publication.

5. How Do You Know the Agent Works?

Once an AI agent is deployed, model accuracy alone is not enough to evaluate it.

Endor Labs proposes evaluating three levels:

Process

Did the agent follow the required evidence path, permissions and approval gates?

Result

Was the recommendation or remediation correct, complete and actionable?

Outcome

Did the resulting change actually reduce risk without introducing regressions?

There is also another important consideration: contestability.

A human reviewer should be able to understand why an agent reached a conclusion, inspect its evidence, identify missing information, challenge the decision and reject or rerun the task when necessary.

This creates a more meaningful form of human oversight than simply placing an "approve" button at the end of an opaque workflow.

6. What Happens When the Agent Fails or Is Attacked?

AI agents operate in environments containing uncertain and potentially untrusted information.

They can encounter:

• Incorrect model reasoning

• Unexpected tool results

• Untrusted repository content

• Network failures

• Interrupted executions

• Adversarial input

A security harness therefore needs failure-handling mechanisms before the agent receives consequential authority.

Endor Labs highlights several controls:

• Fail closed when required proof is missing

• Limit credentials

• Restrict available tools

• Reduce the potential blast radius

• Checkpoint state where appropriate

• Make retries idempotent

• Treat repository contents and tool output as data rather than authority

One particularly important principle is that untrusted text should never become authority.

This is significant for AI coding environments because an agent can encounter instructions inside repositories, documentation, issue descriptions or tool responses.

Those instructions may be useful data, but they should not automatically override the security policy governing the agent.

7. How Should the Agent Change Over Time?

A security harness cannot be treated as a one-time implementation.

The surrounding system can change in several ways:

• Models can change

• Prompts can change

• Tools can change

• Security policies can change

• Evidence schemas can evolve

• Integrations can change

These changes can alter agent behavior even when the overall task appears unchanged.

Endor Labs recommends versioning the task contract and execution context, testing new versions, maintaining rollback paths, monitoring agents in operation and eventually retiring obsolete versions without losing audit history.

Ownership also needs to be explicit.

Organizations need to know who owns:

• The agent

• The platform running the agent

• Security policy

• The affected application

• Incident response when something goes wrong

AI agents can cross traditional boundaries between software engineering, security and operations. That makes clear ownership increasingly important.

Why Security Harnesses Matter for AI Coding

The underlying issue is not that AI coding agents are inherently unsafe.

The issue is that capability and control are different engineering problems.

A model can be highly capable at understanding code while still requiring an external system to determine:

• What information it can access

• What actions it can perform

• What evidence it must have

• When human approval is required

• What happens when validation fails

• How failures are contained

• How changes to the agent are tested

This distinction becomes particularly relevant as organizations move from AI-assisted development toward agents that can independently perform more steps in software workflows.

The security architecture therefore needs to evolve alongside the agent's capabilities.

A Practical Security Harness Framework

The seven questions from Endor Labs can be condensed into a practical framework for teams evaluating AI coding agents:

The specific evidence needed will depend on the security task.

For software composition analysis, an agent may need dependency versions, finding changes, upgrade risks and conflict analysis.

For AI-assisted SAST, the required evidence may include affected code paths, exploit reproduction, data and control flow and remediation guidance.

The evidence changes.

The security questions remain largely consistent.

The Broader Industry Shift

Analysis: The announcement highlights a broader industry shift toward treating AI agents as software systems that require traditional security engineering principles around them.

As coding agents gain access to source repositories, development tools and workflow systems, organizations have to consider not only what the underlying model can generate, but also the boundaries surrounding that capability.

This means concepts such as least privilege, approval gates, auditability, validation, failure containment and change management are increasingly relevant to agentic software development.

The development also reflects growing demand for security controls that operate alongside AI agents rather than relying exclusively on reviewing their output afterward.

Endor Labs' framework provides one approach to this problem. The company itself notes that the evidence contract should change according to the security job while the governing questions remain consistent.

Conclusion

AI coding agents can reason, navigate code and perform increasingly complex development tasks. But greater capability does not automatically provide greater control.

Endor Labs' seven-question framework puts the security harness around the model rather than treating the model itself as the security boundary.

The approach centers on four architectural foundations: define the job, provide trusted evidence, control authority and enforce prerequisites.

It then adds operational safeguards around evaluation, failure containment and controlled change.

For organizations adopting AI coding agents, the practical lesson is clear: security needs to be engineered into the workflow surrounding the model.

The model can remain probabilistic.

The controls around it need to be deliberate and enforceable.