Introducing the DevArmor Agentic Flywheel

What Does 'Agentic Security' Actually Mean?

The security tooling landscape is quickly being taken over by agents: agents that review, agents that scan, agents that pentest, agents that watch other agents. The numbers back the feeling. SANS found that AI use in cybersecurity jumped from 50% to 78% in a single year, and Gartner predicts that 40% of enterprise applications will feature task-specific AI agents this year, up from less than 5% a year ago.

But not everything wearing the label is an agent. An agent, properly defined, is a program that can perceive its environment, make decisions on its own, and take actions toward a goal. A lot of what's shipping today is classic automation with a new name. So much of it that Gartner coined a term for it: "agent washing." Of the thousands of vendors claiming agentic AI, they estimate only about 130 are the real thing, and they predict over 40% of agentic AI projects will be canceled by the end of 2027.

These numbers are important because they mean the burden of proof has shifted. When every product page says "agents," the word tells a buyer nothing. What matters is the architecture underneath and most agentic security architectures, including some very real ones, share a fundamental flaw.

The Problem with AI Security Agents: Automation Without Learning

The obvious way to build an agentic security product is to take the security team's org chart and automate it. One agent does design reviews. One agent writes policies. One agent watches the coding tools. In a demo, it looks like replacing AppSec with agents.

In reality, though, each agent performs a disjoint task. It picks up a task, re-derives context from whatever is in front of it, produces an output, and moves on. It's stateless. The review it finished yesterday teaches today's review nothing. The design question it answered last sprint gets answered again from scratch, and sometimes differently. The exception you granted in Q2 doesn't inform the finding it files in Q3. The risk you already accepted comes back as a brand-new finding, sprint after sprint.

This is automation, and automation scales effort. It does not accumulate knowledge. A roster of stateless agents working a queue is like a call center: more throughput, same conversation, every single day. And anyone who has run a SAST or CSPM program knows where throughput without memory leads to more findings, more triage, more exceptions to re-litigate. It's the same cycle every security tool eventually rides. Agents just ride it faster.

I believe the question that separates platforms is not whether you have agents. It's whether your agents make each other smarter. Without continuity and consistency, each agent does a job, produces an output, and moves to the next ticket. The review it just finished teaches the next review almost nothing. The finding it just filed doesn't make tomorrow's finding less likely. It works like a faster treadmill.

The DevArmor Agentic Flywheel: Seven Agents, One Compounding Security Context

We built DevArmor around the opposite bet: state is the product. Our agents aren't standalone workers, but they're arranged in a loop around one shared asset: your organization's Unified Security Context (Org Memory). It's a knowledge graph built from artifacts your team already produces: your architecture and data flows, trust boundaries, threat models, policies and standards plus the decisions made along the way: accepted risks, granted exceptions, approved patterns, each with its scope and rationale. The context updates from the documents, tickets, and code changes your SDLC already emits.

We call this architecture the DevArmor Agentic Flywheel. A flywheel stores energy: every push makes the next push easier. Here, every agent reads from the shared context and writes its outcome back. In practice, that means a review conclusion becomes precedent the next review can cite. An exception gets recorded with scope and expiry so it stops resurfacing as a new finding. Every turn of the loop leaves the context richer, and that's what makes the next decision faster, cheaper, and more precise.

‍

How DevArmor’s Agentic Flywheel Works: From Design Doc to Enforced Policy

This is best explained with an example. Say your team designs a new payment service. Here's one full turn of the flywheel.

1. Context Collector: 

DevArmor’s Context Collector agent reads the design doc, the Jira epic, the architecture diagram, the relevant code, which are artifacts your team already produces.

It then produces a normalized snapshot of the change, added to your security context.

2. Architecture Composer

DevArmor’s Architecture Composed reads the change snapshot produced by the context collector, plus the existing system model.

It produces: an updated model including new components, new data flows, and a new trust boundary where card data crosses services.

3. Threat Modeler

DevArmor’s Threat Modeler reads the model delta and produces an updated threat model in minutes, flagging the threat classes this specific design opens up.

4. Policy Builder
DevArmor’s Policy Builder reads the new threats, plus your standards and the compliance frameworks you answer to. It then produces enforceable, policy-as-code requirements mapped to those frameworks.

5. Design Advisor
DevArmor’s Design Advisor reads the policies and the full context and produces guidance where building happens; e.g.,  review comments in the design doc (Google Docs, Notion), requirements in the ticket (Jira, Confluence), and AI guardrails in the IDE and over MCP. Your developers and their coding agents get the answers before the vulnerable line is written, not after.

6. Controls Enforcer (Code Reviewer)
DevArmor’s controls Enforcer every PR, checked against the policies. It produces plain-English findings with suggested fixes, and when a change violates a control that matters, it can block the merge. Every block traces back to the design decision that justified it, so nobody argues with a mystery gate.

7. Compliance Reporter
Lastly, DevArmor’s Compliance Reporter reads everything the cycle decided and enforced.
It produces the evidence trail: attestations, framework mappings, audit-ready reports.

The Flywheel Effect: More Security Coverage, Faster Cycles, Lower AI Costs

Security tools get noisier over time. More rules, more alerts, more exceptions, more fatigue. However, the flywheel runs in the opposite direction, because the context compounds.

Concretely, three things get better with every turn:

• Threat models get sharper. Your tenth threat model beats your first because the system isn't re-discovering what your services do. It already knows which flows carry cardholder data, which controls exist, and what you decided last quarter. New findings build on that history instead of repeating it.
• Reviews get faster. Most design review answers are really precedent lookups: this pattern is approved, this control is standard, this exception is documented. The flywheel resolves the precedented majority instantly and routes the genuinely novel cases to your architects, which is where their attention should have been all along.
• Enforcement gets more precise. Policies are tuned by outcomes; e.g., what got blocked, what got fixed, what got excepted and why.

This is also what makes self-service security workable. The scarcest resource on any AppSec team is reviewer attention and time. As coding agents multiply change volume, the review queue slows down to a crawl. The only model that survives is one where every builder, human or AI, serves themselves from a context that's always current and always theirs. 

The loop closes on itself: self-service is only safe because the context compounds, and the context compounds because every self-serve interaction feeds it.

Across our production deployments so far, the flywheel effect has increased security coverage by up to 5x, reduced cycle times by roughly 30%, and made token spend cut by about half.

Why the Unified Security Context is core to the Software Factory

The flywheel is really a claim about where value lives in the agentic era.

Every organization is becoming a software factory. In a factory, the scarce asset isn't labor (the agents provide that), but is institutional knowledge: what this organization builds, what it protects, what it decides, and why. Today that knowledge is scattered across outdated Confluence and Notion pages, departed employees, and the heads of two overworked security architects. It doesn't scale, it doesn't transfer, and it definitely doesn't reach the coding agent writing the code for your next critical service.

The Unified Security Context turns that model on its head. It is that knowledge, made durable, queryable, and enforceable. It is one of the most valuable assets an engineering organization owns: the difference between a factory that repeats its mistakes at machine speed and one that never makes the same mistake twice.

That's the bet behind the flywheel, and it's why we didn't build an agent roster. Rosters do jobs. Flywheels build assets.

There's much more underneath each turn of the wheel; how Org Memory actually works, how coding agents consume the context over MCP, what enforcement-with-provenance means for your auditors. We'll go deep on each in the coming weeks.

Until then, the short version: don't ask your security vendor whether they have agents. Ask what their agents know, and whether they'll know more next month than they do today.