Software agents are writing code, opening pull requests, and deploying to production. Stripe has Minions. Coinbase built Forge. Every serious engineering organization today is figuring out how to run agents at scale, not whether to run them, but how many and how fast.

The emerging consensus is that the software agent stack has three layers:

• A harness that wraps one or more LLMs with specific rules and tool access
• An orchestrator that manages the runtime environment where agents execute
• An agent control plane that provides observability and governance across all agents 

Most of the conversation about the control plane so far has focused on cost management, resource allocation, and developer productivity. Those matter. But they're not the hard problem. The hard problem is security, and it cuts across every layer of the stack.

The agent control plane has a security gap

Consider what a typical coding agent does in a single session. It reads your codebase. It picks open source dependencies. It writes new code, generates tests, accesses MCP tools, and opens a PR. Each of those actions carries security risk.

The agent might introduce a vulnerable dependency. It might write code with a business logic flaw that no linter catches. It might pull in a malicious package planted by an attacker targeting agentic workflows specifically. Prompt injection makes it worse, a poisoned MCP resource, a compromised tool, or a malicious README Skill can hijack an agent's actions entirely, exfiltrating data or executing arbitrary commands.

Only about 10% of AI-generated code is both functionally correct and secure. Meanwhile, pull requests are up 26% as agents ship more code faster. That's a compounding problem: more insecure code, moving faster, with less human review.

Most organizations treat security as a feature of the agent control plane, one dashboard among many. That's not enough. Security needs to be embedded in every layer of the stack. Here's what that looks like.

Security in the harness: secure code at the point of generation

The agent harness is where code gets written. It's also where the most consequential security decisions happen, and where intervention has the highest leverage.

When an agent selects a dependency, it's making a supply chain decision. When it writes a function that handles user input, it's making an authorization decision. When it connects to an MCP server to fetch context, it's making an access control decision. Most agents make all of these decisions with zero security context.

A security-aware harness changes this. It operates at the moment of generation. Through MCP integrations and Skills, security intelligence becomes part of the agent's reasoning loop:

• Code generation gets guided away from insecure patterns. Not a linter that flags problems after the fact, an active participant in the generation step that understands vulnerable APIs, common logic flaws, and the actual data flow of your application.
• Dependency selection gets validated against continuously updated intelligence. Is this package real, or a hallucinated name an attacker has squatted? Is it maintained? Does it contain malicious code? Are known vulnerabilities actually reachable in your application?
• Tool access gets scoped by policy. Which MCP servers can this agent connect to? Which skills are authorized? What data can flow in and out?

This is where the compounding problem gets reversed. If 300 developers each have agents shipping one PR per day, that's 75,000 PRs per year. Catching a vulnerability at generation costs almost nothing. Catching it at review costs an engineer's time. Catching it in production costs a lot more.

Security in the orchestrator: enforce policy at runtime

The orchestrator is where agents run, containers, cloud infrastructure, sandboxed environments. Most discussions about orchestration focus on resource management: CPU, memory, concurrent sessions. But the orchestrator is also the enforcement layer for security policy, and most organizations haven't built that muscle yet.

When agents run on developer laptops, they inherit every secret, credential, and access token on that machine. That's the status quo for most teams today. Even teams running agents in containers often give those containers broad network access, default service account permissions, and no restrictions on external connections.

A security-aware orchestrator enforces boundaries at runtime:

• Secrets scoping. The agent gets only the credentials it needs for a specific task, not everything the developer has access to. When the session ends, those credentials are revoked.
• Network policy. Agents can reach your Git provider and approved package registries. They can't reach Pastebin, arbitrary external APIs, or domains outside an allowlist. (This isn't hypothetical, teams have caught agents trying to use paste services as scratch storage, which is a textbook exfiltration vector.)
• Action-level enforcement. Policy defines not just where agents can run, but what they can do. An agent tasked with writing code shouldn't be able to modify CI/CD configuration, push directly to main, or access production databases. These guardrails need to be defined as code and enforced automatically, not left to agent prompts and good intentions.

Platform engineers already think about infrastructure this way. You scope IAM roles. You define network policies. You enforce resource quotas. Agents are just another workload, but one that makes decisions autonomously, which means the boundaries need to be tighter and the defaults need to be secure.

Security in the agent control plane: observe, audit, and improve

The agent control plane is where you see everything. It's the layer that ties harness and orchestrator together into a governable system.

Most control plane discussions focus on cost, how many tokens are your agents consuming, which projects have the highest spend, where should you downgrade to a cheaper model. Those are real operational questions. But the security questions are harder and more consequential:

• What did each agent do? Not just "it opened a PR," but which model it used, which MCP servers it connected to, which skills were active, which dependencies it resolved, and which files it modified. A full action trace, not a summary.
• Did it comply with policy? Every action compared against organizational guardrails in real time. When something deviates, an unapproved MCP connection, a known-malicious dependency, code that fails a security check, the event is flagged, logged, and optionally blocked.
• What can we learn? Audit logs aren't just for incident response. They're how you improve. Which agent workflows produce the most security findings? Which dependency recommendations get overridden? Where are agents consistently hitting policy guardrails? This data feeds back into harness tuning, orchestrator policy, and developer guidance.

The goal isn't a dashboard you check after something goes wrong. It's a continuous governance loop where security intelligence flows through every layer: harness → orchestrator → agent control plane → back to the harness.

An agent control plane without security isn't a control plane at all

The temptation is to treat agent governance as a single product problem. Build a control plane, add some security features, call it done.

That won't work. Security has to be embedded in the harness where code is generated, enforced by the orchestrator where agents run, and observed through the control plane where teams govern. Miss any layer, and you have a gap.

This is the direction we're building toward at Endor Labs. AURI already operates as a security harness for agentic development, working alongside coding agents through MCP, Skills, Hooks, and CLI to secure code at the point of generation. But the harness is just one layer. The organizations running hundreds or thousands of agents need security that spans the full stack: generation, runtime, and governance.

Every engineering team scaling agents will need this. The only question is whether you build it before the first incident, or after.