If you have been researching AI agents in cybersecurity lately, you have probably noticed a pattern. There is no shortage of predictions, product pages, and conference talks. What is much harder to find is a concrete account of how these systems are actually built: what the architecture looks like, where the guardrails go, and what breaks along the way.
This post is our attempt at that account. We will define what a security agent actually is, explain why security work suits agents better than most domains, walk through the single-agent-versus-team question that every implementation eventually faces, and then show how all of it played out when we built our own fleet of four: Scout, Scalpel, Suture, and Sentry. By the end, you should have a working mental model you can apply whether you are evaluating tools or building your own.
What Is an AI Security Agent, Exactly?
The term gets used loosely, so it is worth pinning down. A script is not an agent: it follows fixed steps in a fixed order, and it fails the moment reality deviates from the plan. A scanner is not quite an agent either: it runs a catalog of checks and reports matches. Both are automation, and both are useful, but neither decides anything.
An agent is different in three ways. It perceives: it builds and updates its own picture of the environment instead of working from a static checklist. It reasons: given a goal, it plans a next action, observes the result, and adjusts. And it acts through tools: it queries DNS, sends requests, reads code, opens pull requests. With LLM-based agents, the reasoning step is where the technology earns its keep, because security work is full of situations that do not match a signature: an endpoint that behaves differently under unusual parameters, a dependency whose CVE only matters given a specific call path.
It also helps to think of autonomy as a spectrum rather than a property. An agent can suggest, an agent can act under human approval, or an agent can act autonomously within a defined scope. Most of the design effort in a serious system goes into deciding which parts of the spectrum apply to which tasks. We will come back to that point, because it turned out to be the most important one.
Why Security Work Suits Agents
Security has a reputation for being adversarial and creative, and the top tier of it is. But most day-to-day security work is volume work: enumerating what exists, diffing what changed, replaying tests, cross-referencing dependencies against public CVE feeds, and checking that yesterday's fixes still hold. It is repetitive, it is detail-hungry, and it competes with everything else an engineering team needs to ship.
This combination suits agents unusually well, for two reasons. First, the work is verifiable. A proof-of-concept either reproduces or it does not. A regression test either fails before a patch and passes after it, or it does not. Verifiable feedback is exactly what an agent needs to tell progress from noise, and it is a large part of why security tasks have proven friendlier to agent designs than many other domains. Second, the bottleneck is attention, not intelligence. Teams generally know what good security hygiene looks like; they simply cannot apply it everywhere at once, on every deploy, at every hour.
The honest framing is workload, not menace. Agents will not replace security judgment. What they do well is carry the repetitive middle of the work so that human attention concentrates on the decisions at the edges: what risk is acceptable, what gets merged, and what changes next.
One Agent or a Multi-Agent Team?
Every implementation we know of starts the same way: one agent with a big toolbox. One system that enumerates, tests, fixes, and watches. It is the simplest architecture to build, and it demos well.
It also runs into three structural limits once you operate it continuously.
Context does not scale. A production surface generates an enormous amount of low-level detail: route lists, DNS records, dependency trees, JS bundles, auth flows. Pulling all of it into the same context that needs to reason carefully about a patch is counterproductive. Enumeration is a high-volume task, patching is a high-stakes task, and they compete for the same attention.
Separation of duties applies to agents too. A system that both discovers vulnerabilities and decides how production gets changed is a conflict of interest. Security teams have understood this for decades: the person who finds a flaw is rarely the only person who signs off on the fix. Splitting detection, remediation, and verification across agents makes the whole pipeline more auditable, not less.
Failures need to be legible. When a generalist misbehaves, you audit everything. When a specialist misbehaves, you know exactly which subsystem to inspect, which guardrail to tighten, and which regression suite to extend. One job per agent also means one failure mode per agent, and that is essential for day-to-day operations.
None of this division is new. It mirrors how strong security teams already organize themselves: recon, offensive testing, remediation, and release verification have always been different disciplines. We simply gave each one a dedicated operator.
A Working Example: The Four Agents We Built
That is the theory. Here is how it translated when we built syber. Our fleet has four agents, each with one job and one primary output that the next stage consumes.
Scout: the recon agent
Scout answers a deceptively simple question: what is actually running? It enumerates routes, subdomains, forms, tokens, third-party integrations, dependency graphs, and authentication flows, and assembles them into a single structured map of the application's externally visible surface. Two decisions matter most in a recon agent. The map should be an artifact, not a report: ours is a versioned surface graph that other agents query programmatically. And the map should never be finished: Scout re-reconciles it on every deploy and on a standing schedule, because surfaces drift and a stale map produces confident, wrong results. Freshness, more than raw coverage, is the metric that keeps everything downstream trustworthy.
Scalpel: the testing agent
Scalpel takes Scout's map and runs adversarial testing against it: the OWASP Top Ten and a long tail beyond, from injection classes and session flaws to SSRF and business-logic probes, cross-referenced against more than 1,284 CVE signatures. Its defining rule comes from the disciplined end of the penetration testing world: no proof, no finding. Every reported vulnerability must include a working proof-of-concept that demonstrates the issue non-destructively, enough to prove it exists and never enough to exploit it at scale. The rule eliminates the vague alerts that make engineers distrust scanners, and it forces verification to be built into the agent itself. Findings are ranked by blast radius rather than CVSS alone: what an attacker could actually reach, and how many users it would touch.
Suture: the remediation agent
Suture writes the fix: the patch, the dependency upgrade, the config hardening, the secret rotation. It is where we invested most heavily in guardrails, because it is the only agent whose output changes production code. Its rules are conservative. It produces the smallest viable fix, one finding at a time, with no opportunistic refactoring mixed in. Every patch ships with a scoped regression test that fails before the fix and passes after it. And every fix goes through the normal pull request flow: Suture opens the PR with a plain explanation, and a human reviews and merges it. When confidence is low, it does not force the issue. It prepares a proposed patch, documents the uncertainty, and routes the decision to the team. A remediation agent earns autonomy one merged PR at a time.
Sentry: the deploy watcher
Sentry exists because deploys are where regressions are born. It hooks into the CI/CD pipeline and treats every deploy as an event worth testing: it diffs the new release against the last known surface, identifies what changed, and replays the relevant probes against exactly that delta. Diff-aware testing is what makes the latency budget work. Re-testing an entire application on every push would be impractical; testing only what changed brings our median time from deploy to verified result down to 89 seconds, across a fleet that scans well over a million requests per day. Previously fixed findings are re-checked on every subsequent deploy, so the regression suite for every closed issue never retires.
Guardrails That Make Autonomous Agents Safe to Run
Everything above sounds tidy in a post and messier in production, so it is worth being explicit about what keeps an agent fleet safe to operate. The patterns we rely on are not exotic, but they are non-negotiable.
Least privilege per agent. Each agent gets the minimum toolset its job requires, and nothing more. Scout reads, Scalpel probes within defined limits, Suture writes through a single PR path, Sentry observes the pipeline. Nobody holds all the keys.
Graduated autonomy. Every agent started read-only, then earned write capabilities in limited domains, then expanded only as accuracy proved out over weeks of real operation. Autonomy is a dial, not a switch, and it is granted per task rather than globally.
Explicit handoff contracts. A finding is not real until it carries a PoC. A patch is not done until its regression test passes and a human merges. A deploy is not live until Sentry has lit it green. The pipeline is only as strong as its handoffs, so the contracts between stages are written down and enforced in code.
Escalation by default. When any agent hits the edge of its confidence, the correct behavior is to stop and hand the decision to a human rather than guess. Design for the exit, and teams will actually let the system run.
Evaluating Security Agents: Five Questions Worth Asking
If you are comparing autonomous security tools, or sketching your own, the marketing will tell you about coverage and speed. These five questions tell you about architecture.
-
What can the agent do without asking? The answer defines its real autonomy, whatever the deck claims. Look for a precise, documented scope of unattended actions.
-
How does it prove what it finds? A finding without a reproducible proof-of-concept is a hypothesis. Agents that enforce PoCs produce fewer, better findings.
-
What does it do when unsure? Confident systems are not the ones that are never unsure; they are the ones that know how to stop and escalate.
-
What is the blast radius of its worst mistake? Ask what the agent can write, where, and under whose approval. A single constrained write path with human review is worth more than a dozen impressive demos.
-
How current is its view of the environment? Agents act on a model of your surface. If that model is not continuously reconciled with reality, everything downstream inherits the staleness.
The same questions shaped our own build, which is why the fleet looks the way it does: four narrow agents, explicit contracts between them, and humans at every merge gate.
Where This Leaves Us
AI agents in cybersecurity are moving fast, but the principles underneath them are settling down. Verifiable work suits agents. Volume work suits agents. Narrow scope beats broad capability, separation of duties survives the transition from humans to software, and autonomy should be earned rather than granted.
We built four agents because the work was always four jobs. If you are building your own, start with one narrow job, instrument it well, expand on evidence, and keep a human at the merge gate. The fleet will grow from there.