AI coding agents write real production code today. Application security was built on an assumption that no longer holds: that a person read every line before it merged. Now there's more code, shipped faster, with less human review at each step.
The term you'll hear for the fix is a security harness.
A security harness, defined
A security harness for AI coding agents is the engineered control layer wrapped around an agent. It governs what the agent can access, what actions it takes, and the security of the code and open-source dependencies it produces.
A simple model helps: agent = model + harness. The model reasons and writes. The harness enforces the rules and checks the output.
People often confuse a harness with guardrails. Guardrails are policies on an agent's inputs, outputs, and actions. A harness is the wider control layer that also judges the code and dependencies the agent leaves behind.
| Aspect | Security harness | AI guardrails |
|---|---|---|
| What it is | The control layer around the agent | Policies on inputs, outputs, and actions |
| Scope | Access, actions, and the code and dependencies produced | Mostly the agent's prompts and responses |
| Question it answers | Is what the agent shipped actually safe? | Is this input or output allowed? |
An agent has plenty of capability but little security context. In our AI coding agent benchmark, we found agents can produce working code yet miss security basics. The harness supplies the context they lack. AURI by Endor Labs, the security intelligence layer for agentic software development, is built to be that harness. It works alongside AI coding agents as they write, instead of reviewing their work days later.
Why AI coding agents need a harness now
AI coding is the default way many teams build. The Stack Overflow 2025 Developer Survey found that 84% of developers are using or planning to use AI tools. And 51% of professional developers use them daily.
The enterprise trend points the same way. Gartner predicts that 90% of enterprise software engineers will use AI code assistants by 2028, up from less than 14% in early 2024.
Agents optimize for code that works, not code that's secure. They produce larger commits, more often, with less review at each step. The problem got bigger and faster at the same time.
Security leaders feel the gap. A Salt Security survey found 9 in 10 security leaders are concerned about the security risks introduced by AI-generated code. Yet 38% still rely primarily on manual review, which can't keep pace.
Every hour spent chasing a finding that doesn't apply is an hour lost to outer-loop work. Alert fatigue is a velocity problem before it's a security one.
For engineering leaders, slowing down isn't a realistic option. The fix is tooling that keeps developers fast while handling risk in the background.
What a security harness actually governs
A harness covers three kinds of security decisions that used to belong to a developer, and that an agent now makes at machine speed.
- Runtime behavior: The actions the agent takes as it works.
- Generated code: The security of what the agent writes.
- Dependencies: The open-source packages the agent pulls in.
Most tooling covers the first. That leaves the code and dependencies an agent produces largely unguarded, which is where the risk accumulates.
The actions an agent takes
The first surface is what the agent does at runtime: tool calls, shell commands, and file edits. Each one changes something.
Agents can also be manipulated. Prompt injection means feeding an agent hidden instructions that hijack its behavior. It tops the OWASP Top 10 for large language model (LLM) applications, ranked LLM01 in the 2025 list.
A harness also records what the agent did. Audit logs of tool calls and file edits let you reconstruct any action later, so runtime behavior can be reviewed after the fact rather than merely watched.
Runtime controls like sandboxing and approval gates help here. But they watch what the agent does. They don't judge the security quality of the code it commits.
Working code isn't always secure code
The second surface is the code itself. Agents write fluent, working code. But working code is not the same as secure code.
The gap is measurable. In the Veracode 2025 GenAI Code Security Report, 45% of AI code samples failed security tests and introduced OWASP Top 10 vulnerabilities.
Common flaws include injection bugs, weak cryptography, and hardcoded secrets. At agent speed, the real problem is volume: more findings than any team can triage by hand.
One agent can open dozens of PRs a day. A small failure rate turns into a large backlog fast. Reviewers can't read every line as closely as they once did.
Hardcoded secrets are a clear example. An agent may paste an API key into a file just to make a test pass. A harness should catch that secret before it reaches the repository.
Agents make supply chain decisions on your behalf
The third surface is the most neglected. Agents suggest and install open-source packages as they work, including outdated or vulnerable ones.
They also pull in transitive dependencies, the packages your packages depend on, which you never chose directly. Risk hides deep in that chain.
Sometimes agents invent packages that don't exist. Attackers register those hallucinated names and fill them with malware, a trick called slopsquatting.
The scale is documented. A USENIX Security 2025 study found the average share of hallucinated package names is at least 5.2% for commercial models and 21.7% for open-source models.
Our research on when AI imports vulnerable dependencies shows agents often add packages with known flaws. And our open source malware research recorded 13.6x more malware advisories since January 2024.
Response speed matters as much as detection here. When the Shai-Hulud npm attack hit, Rubrik's security team confirmed it wasn't using any affected versions from 187 compromised packages within about 30 minutes of the attack becoming public.
This surface matters because most modern software is borrowed code. By Endor Labs' count, 70% to 90% of a modern app's code is open source, so the packages an agent adds largely are the app.
That's why dependency governance belongs inside the harness, not beside it. An agent that installs a package is making a supply chain decision on your behalf. The harness should check that decision before the code merges.
Why most harnesses fall short
Many "harnesses" just pile on alerts and generic guardrails. Developers drown in noise, and the agent gets blocked anyway. A useful harness leads with evidence, meaning proof of what's actually reachable and exploitable, so it guides instead of gates.
Three capabilities make that shift real: prioritization that reduces work rather than adding alerts, reachability evidence behind every finding, and enforcement deterministic enough to hold. Each one maps to a decision engineering leaders already make.
Reachability tells you what actually matters
Reachability analysis asks a simple question: does your code actually call the vulnerable function? If nothing reaches it, the finding is noise.
Think of it like worrying only about the doors that are actually unlocked. You stop checking every door in the building and focus on the few that matter.
That focus is why Endor Labs' reachability-based dependency analysis cuts up to 92% of dependency noise by proving exploitability. In Endor Labs data, fewer than 9.5% of vulnerabilities are exploitable at the function level.
Cursor's security team saw the same pattern. Only 2.5% of the findings in their codebase were reachable, so a small team could stop researching the other 97.5% by hand and focus on what was actually exploitable.
AURI applies full-stack reachability across code, dependencies, and containers. It cuts up to 95% of alert noise at each layer, so developers act on the few findings that matter.
Deterministic policy hooks instead of prompts
Putting "please follow our standards" in a prompt is probabilistic. The model might comply, or it might not. You can't count on it.
Deterministic enforcement is different. AURI for Developers includes deterministic agent governance: auditable hooks that observe every consequential agent action. Each action is allowed or denied against a centralized policy, independent of the AI model.
Determinism matters most for non-deterministic systems. When the agent's output varies, the control around it can't.
Safe fixes backed by proof
Flagging a problem is only half the job. A harness should also guide a safe fix.
That means upgrade paths that won't break the build, with impact analysis that shows what changed between versions. When upgrading isn't an option, backported patches fix the flaw on your own timeline.
This is where developer velocity shows up directly. In Endor Labs data, findings caught during development, not at review, drive 83% fewer blocked PRs.
How to put a security harness in place
You don't need to rebuild your security program to start. Treat the harness as a short sequence of practical choices.
- Inventory the agents: Map where agents run and what they can access.
- Enforce at generation time: Apply deterministic policy in the developer's workflow, not after commit.
- Prioritize by reachability: Rank findings by what's exploitable, not by raw counts.
- Govern dependencies: Check the open-source packages agents add, including transitive ones.
- Require evidence: Demand proof for both the risk and the fix.
Done well, this makes security the default output of agentic development. For a deeper walkthrough, see our practitioner guide to securing AI-native development.
What's next
Speed and safety don't have to trade off. A harness that leads with evidence lets your team ship fast and stay secure: code without compromise.
Start with the surface you can already see. Inventory where your agents run and what they can touch, and the rest of the harness builds out from there.
Book a demo to see how AURI puts a security harness around your coding agents.
Frequently asked questions
What is a security harness for AI coding agents?
It's the engineered control layer around an AI coding agent. It governs what the agent can access, what it does, and the security of the code and dependencies it produces.
Why do AI coding agents need a security harness?
Because agents make three kinds of security decisions at machine speed: what actions to take, what code to write, and what open-source packages to install. Manual review can't keep pace with all three, so the checks have to run alongside the agent.
What's the difference between a security harness and AI guardrails?
Guardrails are policies applied to an agent's inputs, outputs, and actions. A harness is the wider control layer that also judges the code and dependencies the agent leaves behind.
What is an agent harness?
An agent harness is the execution and control layer wrapped around an AI agent. A security harness is the part focused on keeping its actions and output safe.
Do rules files or prompts keep AI-generated code secure?
Not reliably, because prompts are probabilistic and a model may ignore them. Deterministic hooks that allow or deny actions against policy are what actually hold.
How is securing AI-generated code different from traditional AppSec?
The volume and speed are higher, so prioritizing by reachability, meaning what's actually exploitable, matters more than ever to avoid overwhelming developers with alerts.
What is slopsquatting?
Slopsquatting is when attackers register package names that AI tools hallucinate, so a developer who trusts an invented name installs malware instead.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: