The Agentic Security Stack: Emerging Architectural Patterns

Software development is rapidly becoming fully agentic, and the corresponding security stack is trying to keep up. If coding agents can produce and modify software much faster than humans can review it, security agents need to be able to find, fix, and validate vulnerabilities autonomously.

Newer models are increasingly capable of reasoning about security, and frontier labs are explicitly giving their coding systems dedicated security capabilities. But there is also going to be much more code, produced by increasingly autonomous workers, while the systems attacking and defending it get more capable at the same time. Even if generated code becomes more secure on average, that does not necessarily make the aggregate security problem smaller.

And it raises some interesting questions. Should the model that generated a change also be responsible for deciding whether it is secure? What should a coding agent be allowed to execute, install, or access while it works? Which parts of security review still belong to deterministic scanners, and which require model reasoning?

A large market is forming around different answers to those questions. Newer products are not simply adding AI to SAST or scanning generated code more frequently. They are putting security directly into agentic development loops, building controls around the workers themselves, and making remediation and offensive testing increasingly autonomous.

Looking across this new security stack, several architectural patterns are emerging.

1. Secure the Factory

One of the clearest architectural trends is to think about the problem from the perspective of the agent doing the work: the worker.

Traditional AppSec primarily evaluates artifacts such as source code, dependencies, containers, and IaC. Coding agents introduce another system above those artifacts. They read repositories, choose dependencies, call tools, execute commands, load skills, connect to MCP servers, access credentials, and make changes with increasingly limited human involvement.

Snyk calls the resulting category Agentic Development Security. Its model separates the problem into what agents use, what agents do, and what agents generate. Endor Labs uses essentially the same definition, describing agentic development security as protecting the entire process when agents generate, select, and ship code on their own.

In other words, secure code doesn’t mean the agent worker was secure. It may have exposed a credential, installed a malicious dependency, run an unsafe command, or been manipulated by an MCP server or skill.

Endor Labs’ AURI, for example, spans code, dependencies, agent actions, skills, MCP servers, and other parts of the agentic development environment rather than treating code scanning as the entire problem.

The security boundary therefore has to expand beyond the code to the worker itself, including its environment, tools, permissions, inputs, actions, and output.

2. Frontier Labs and Security Agents

The frontier labs are investing heavily in their own security solutions. OpenAI’s Codex Security connects to a repository, constructs a threat model around entry points and trust boundaries, investigates potential vulnerabilities, attempts to validate them in an isolated environment, and proposes fixes. It is designed to behave more like a security researcher than a traditional scanner.

Anthropic has been moving in the same general direction around Claude Code, while security vendors are increasingly integrating directly into the coding agent loop.

Semgrep Guardian, for example, installs into coding agents through MCP, hooks, and skills so scans can run when an agent writes a file rather than waiting for a later CI gate.

There is a strong architectural argument for keeping security close to generation. The coding system already have the rich context about the repository, the requested change, the files it inspected, and why it made particular implementation decisions. Problems can be found and corrected while that context is still available.

But there is another question underneath this architecture: should the model or vendor generating the code also be responsible for deciding whether that code is secure?

3. Separate the Generator From the Reviewer

A growing group of companies are building around the idea of separating code generation from verification. The coding agent produces a candidate change, but another independent system establishes whether there is enough evidence to trust it.

Sonar’s Gitar is positioned around the verification bottleneck created by agentic development. Rather than stopping at code review, it reviews changes, diagnoses CI failures, applies fixes under supervision, and produces evidence that the resulting change passes CI.

DryRun Security describes itself directly as an independent security verification layer. Its agents build contextual understanding of an application and review human and AI generated changes for injection, authorization, business logic, and other problems. Corgea adds to this by checking tickets, designs, and specifications against the actual repository before implementation.

These approaches mirror a pattern already appearing elsewhere in agent systems: workers and supervisors have different responsibilities rather than asking one autonomous worker to make every decision about its own output.

4. A Control Plane Around the Agent

Another class of products is focused on what the agent is allowed to do while producing code.

Fiddler, following its acquisition of Lumeus, explicitly describes an AI Control Plane around coding agents. The system extends across the IDE, CLI, MCP boundary, and runtime, with the goal of observing and governing agent behavior rather than simply evaluating the code after it exists.

Salt Code takes a similar vendor-independent approach. Security policies can be applied across Cursor, Copilot, Claude, and other MCP-compatible coding agents at the point of generation rather than being tied to one model or waiting for downstream scanning. Salt extends the same policies into CI/CD and runtime monitoring.

Sandboxing, identity, credentials, and network policy fit naturally into this architecture. The worker can execute inside an isolated environment, receive an identity scoped to a particular job, and get short-lived access only to the resources required for that work.

This speaks to an overall trend in agentic software where many important security decisions occur outside of the context window itself.

5. Securing the Agent’s Supply Chain

Traditional applications consume packages and libraries, while coding agents consume MCP servers, skills, plugins, hooks, instruction files, and models. Those assets may never appear in the resulting application, but they can determine what the agent does while building it.

JFrog’s Agent Skills Registry treats skills much like other governed software artifacts. Skills can be versioned, scanned for malicious behavior, cryptographically signed, access-controlled, and distributed from a trusted system of record. Its MCP Registry applies the same architecture to MCP servers and individual tools, including the ability to block unapproved servers before an agent can use them.

Corgea has independently arrived at a similar model for skills. It scans SKILL.md instructions before developers install them and distributes approved versions through a governed registry. Snyk approaches the problem from the runtime side, controlling which MCP servers and tools coding agents are allowed to use while they operate.

6. AppSec Agents

Another trend is moving from automating security scans to automating more of the security workflow itself. Agents can increasingly investigate findings, decide what matters, generate fixes, and validate that those fixes worked.

Checkmarx calls its approach self-healing application security. Developer Assist runs a continuous find-and-fix loop inside coding tools, while separate triage and remediation agents work through existing vulnerabilities. The system can detect a vulnerability, retrieve additional context, generate a fix, and verify it before the code is committed.

Legit Security is focused on the remediation part of the workflow as well. Its agents independently prioritize findings, generate fixes, open pull requests, and confirm results using context from the organization’s codebase. They can work across multiple affected services in parallel rather than waiting for humans to work through the vulnerability backlog sequentially.

As more of the workflow becomes autonomous, the role of the human increasingly focuses on configuring policy, exceptions, and the cases where the agents are uncertain or disagree.

7. Model-Based Scanning

Some of the more interesting new architectures look at how scanning can extend beyond the limits of deterministic analysis by using AI scanning powered by reasoning models.

Wiz’s Agentic Code Security routes between deterministic and non-deterministic scanning based on speed, depth, and cost. Continuous deterministic analysis covers the cheap and well-understood cases, AI scanning handles more contextual and logic-based vulnerabilities, and deeper agentic investigation can be reserved for changes that are risky enough to justify the expense.

Cycode’s Agentic Code Scanning has four layers instead of two: deterministic SAST, AI-generated deterministic SAST rules, AI exploitability analysis over scanner findings, and agentic code scanning for vulnerability classes that cannot be expressed effectively through rules.

In these new products, models handle ambiguity, application context, and previously unknown patterns, while deterministic systems handle what we already know how to express precisely and cheaply.

8. Pentesting In the Loop

The offensive side is undergoing a similar transition. Pentesting has traditionally been comprehensive but infrequent because applications change so rapidly.

Agentic pentesting changes the economics by allowing more continuous testing. Invicti Agentic Pentest combines autonomous reasoning with proof-based DAST, allowing the agent to explore while deterministic techniques validate exploitable vulnerabilities. Invicti explicitly positions the product against the mismatch between daily software releases and periodic manual penetration tests.

Bugcrowd’s Savant Pathseeker uses specialized agents for reconnaissance, planning, exploitation, and reporting. It can operate in pre-production or production and return evidence of whether an attempted exploit actually succeeded.

Wiz Red Agent similarly acts as a context-aware attacker against applications and APIs, reasoning about application behavior and validating exploitable risks rather than only identifying suspicious patterns.

One of the newest entrants, Armadin, takes the idea beyond individual vulnerability discovery. Its autonomous agents perform reconnaissance, probe weaknesses in parallel, and attempt to assemble validated weaknesses into complete paths to compromise.

Offensive agents can provide a continuous source of evidence that can be folded back into the development process.

The Evolving Security Stack

Security architecture is starting to mirror software development architecture. Both are increasingly agentic and autonomous, and they must be co-developed in lockstep.

At the same time, this is very much an emerging and evolving space. Coding agents are changing quickly, and the security architecture around them is being built in real time. Many of the categories above overlap, and I expect the boundaries between them to keep moving.

What seems clear is that securing the code is no longer enough. We also have to secure the worker producing it, control what that worker can do, independently verify its output, and give the security side enough autonomy to keep pace.