How Endor Labs Is Securing the AI Coding Harness Era

Over the past year and a half, software development has undergone a significant shift—but many security teams are still playing catch-up.

These AI-powered coding tools like Cursor, Claude Code, and those newfangled autonomous coding agents—have long since shed their fancy autocomplete skin. Today, they can read entire code repositories, tinker with files across an entire project, install dependencies, fire off internal tools, and run shell commands with ease. Some can even keep cranking out code for hours while the developer is only loosely paying attention.

In a Software Plaza webinar, Twain Taylor, editor at Software Plaza, spoke with Endor Labs about what this shift means for application security. The discussion centered on a point that is easy to miss: the risk is not only in the code an AI tool writes. It is also in the environment around the model, the permissions it receives, the systems it can reach, and the actions it can take while helping a developer. 

It’s no longer just a productivity feature, that’s for sure. It’s more like having a mechanical engineering worker lurking in your development environment.

Why Endor Labs is talking about the AI coding harness

Endor Labs has been paying close attention to what this means for app security, and one idea that’s caught their eye is the “AI coding harness”. The term might sound a bit awkward, but basically, all it means is the model is just one part of the puzzle.

The harness is everything around the model

That’s the thing about this harness business: it includes the IDE, all the plugins, MCP servers, permissions, prompts, workspace access, package sources, command-line tools, and all the internal integrations. And here’s the thing: the same model can behave completely differently depending on the harness it gets to live with.

In one setup, it’s a limited coding assistant that just suggests changes. In another, it’s got access to a developer’s machine, internal repositories, build scripts, package managers, cloud tools, and shell commands. At that point, it’s not just helpful code tweaks – it’s got a whole playground.

The security problem is way bigger than bad code

You can’t just focus on whether the AI writes vulnerable code – that matters, but it’s not the whole story. The real question is what the agent is allowed to do while it’s helping out.

• Can it read sensitive files? 
• Can it mess with production code?
• Can it install packages? 
• Can it run arbitrary commands? 
• Can it call internal APIs? 
• Can it connect to some MCP server that has access to private systems?

It’s where the attack surface starts to get weird.

Agents make decisions at machine speed

An agentic coding tool starts making decisions in the blink of an eye – decisions that used to be firmly in the developer’s court. It might pick which package to install, which files to tinker with, which auth pattern to use, and which commands to run while testing out the change.

The developer might not even know about half this stuff until they see the final result: a feature that works like magic.

From a security perspective, though, every one of those decisions happens at machine speed, with barely any review and no clear proof of who okayed any of it.

Where Endor Labs is focusing

The thing we’re really getting at at Endor Labs is that to secure these things, companies have got to secure the harness itself, which is all the stuff that lets the AI model do its thing. That means monitoring which AI models are being used, what plug-ins are turned on, which files the agents have access to, which MCP servers are trusted, which commands are blocked, and which package registries are okay.

These are not some vague policy questions we’re talking about here. We’re talking about the actual control points that decide what an AI agent can do while it’s running.

Enterprises don’t have enough visibility

Most companies don’t have enough visibility into this layer yet. They might know which repositories they own, which scanners are running in CI, and which dependencies are in production. But they probably don’t know which AI coding tools the developers are using on a day-to-day basis, what permissions have been granted, or which internal systems are connected through those agent workflows.

The harness has basically become part of the development infrastructure – but a lot of enterprises are still not treating it that way.

Why a simple AI code policy won’t cut it

A simple policy that says devs have to review AI-generated code is just not going to solve the problem. Companies can say all they want about reviewing code, but that doesn’t actually secure the place where that code was created.

The real environment can change at any time someone connects a new tool, turns on a plug-in, adds an MCP server, or grants the agent another permission.

The harness is always changing, so the security around it has to change too.

The better approach is governance

The companies that are best prepared are not always the ones with the strictest rules. They’re the ones treating AI coding environments like real infrastructure – they’re asking practical questions like what should agents be allowed to do, what should need approval, what should be logged, and what should be completely blocked.

That shift matters. Once you start thinking of AI coding tools as autonomous actors inside the environment, the security model starts to make a lot more sense – it needs permissions, monitoring, policy enforcement, package controls, trusted tool boundaries, and real-time feedback.

And it also needs security checks early enough to actually shape what the agent does next – not just send out alerts after the fact.

What teams should take from the webinar?

The main takeaway from Endor Labs’ view is that AI coding risk will be shaped by more than model behavior. The model still matters, but the harness decides what the agent can read, change, install, execute, and expose.

That is where security teams need to focus now. Blocking AI coding outright is unlikely to hold for long, especially when developers are already using these tools to move faster. A better path is to treat AI coding environments as part of the engineering stack.

That means giving agents useful access without making broad trust the default. It means setting boundaries around package installs, shell commands, MCP servers, internal APIs, secrets, and production-related files. It also means creating checks close enough to the development workflow that they can shape what the agent does next, rather than only flagging problems after a pull request is opened.

For teams trying to understand where AI coding risk is headed, the full webinar is worth watching. It goes deeper into how Endor Labs thinks about the AI coding harness, why older AppSec workflows are under strain, and what companies can do to govern coding agents without slowing developers to a crawl.