Evidence note: This article rests almost entirely on how projects describe themselves — public repository documentation, project READMEs, and vendor developer-blog posts. None of the systems named here were installed, run, or benchmarked for this piece, and no independent corroboration of their architectures, components, or effectiveness was found. Self-descriptions are evidence that a project claims a design, not that the design works as claimed or that the code matches the prose. Individual claims carry their own evidence marker below; where a point is inference drawn across several sources rather than something a source states, it is labelled as such.
What the current agentic cybersecurity record actually names
Search for "adaptive agentic cybersecurity" and the results are not a product category. They are a scattering of independently published open-source repositories, each describing a system that detects, investigates, decides on, acts against, and evaluates security incidents — with some form of adaptation in the loop. Projects presenting themselves this way include AgentShieldAI, an autonomous cyber immune system called ACIS, ACDADA, AegisAI, and CyberTwin. (Evidence level: each project’s own repository description; the existence of the repositories is checkable, but neither their functionality nor their maturity has been independently verified, and none appears to have third-party evaluation behind it.)
That distinction matters for how the rest of this article should be read. What follows is a survey of stated designs. It is a reasonable map of what builders in this space say they are building; it is not a map of what runs reliably in production.
The shape they converge on: one specialised agent per incident stage
Across these projects, a recurring structure appears: rather than one general-purpose security agent, the work is split into specialised agents, each owning a stage of the incident pipeline — monitoring, anomaly detection, classification, risk evaluation, and response action. (Evidence level: a pattern observed across the projects’ own descriptions; no source states this as an established industry norm, and the sample here is small and self-selected, so "typical" is an impression from the available repositories rather than a measured finding.)
The convergence is worth noting precisely because it is not obviously necessary. An LLM with tool access could in principle read the log line, decide it is anomalous, classify it, and fire the containment action in a single trajectory. The staged split says something about what builders found workable — a point an earlier article on this site about how lead agents coordinate specialized subagents took up from the coordination side.
Inside CyberTwin: Apache Kafka for the event stream, LangGraph for the agent graph
CyberTwin is the most legible of the set because its stated component list is specific. It describes itself as a digital twin platform for adaptive cybersecurity monitoring, using Apache Kafka for real-time security-event streaming, LangGraph to orchestrate a set of agents named Monitor, Anomaly Detection, Classification and Action, and Isolation Forest for the anomaly detection step itself. (Evidence level: the project’s own repository description; the component choices have not been independently verified, and no throughput, latency, or detection-quality figures are available to check.)
Specificity like this is unusual and useful. Kafka and LangGraph are both ordinary, widely deployed pieces of infrastructure, which means the claimed design is at least plausible on its face: a durable event log feeding a stateful agent graph is a shape many teams already run for non-security workloads.
The anomaly detection agent does not call a language model to detect
The most instructive detail in CyberTwin’s stated stack is that the agent called "Anomaly Detection" reportedly does its detection with Isolation Forest — a classical unsupervised outlier-detection algorithm, not a language model. (Evidence level: the project’s own description, as above.)
The reading that follows is inference, not a claim any source makes: if the stated design is accurate, the word "agent" in that pipeline stage is describing an orchestration role, not a model call. The LLM’s contribution sits around the detector — routing events, interpreting what the detector flagged, deciding escalation — while the numerical judgment of "is this point unusual" stays with a deterministic, cheap, auditable algorithm.
That division has practical consequences worth weighing even in the absence of verification. A statistical detector has a fixed cost per event, produces a score that can be thresholded and regression-tested, and does not hallucinate. A language model asked to eyeball raw telemetry has none of those properties. Whether other projects in this space make the same split is not established by the available sources.
Why the model stack turns out to be swappable: APDM on Google ADK and Gemini
The same architectural pattern shows up on model stacks with no NVIDIA component in them. APDM, an adaptive phishing defense system, describes itself as a multi-agent cybersecurity system built on Google’s Agent Development Kit and Gemini. (Evidence level: the project’s own repository description; not independently verified.)
If both the Gemini-based and the LangGraph-based systems really do decompose into per-stage agents, the implication — again, inference rather than a sourced claim — is that the multi-agent decomposition is a property of the incident-response problem, not of any vendor’s tooling. The orchestration framework is a swappable dependency.
Where NVIDIA Nemotron actually sits: a video search and summarization blueprint, not a security one
Nemotron surfaces in searches adjacent to this topic, which invites an assumption worth correcting carefully. The prominent artefact is NVIDIA’s AI Blueprint for video search and summarization — a reference architecture for building video-understanding agents.
What that blueprint is composed of is open. Descriptions circulating around it say it is GPU-accelerated and combines vision language models such as NVIDIA Cosmos, LLMs such as Nemotron, retrieval-augmented generation, and NVIDIA NIM microservices to produce real-time verified alerts, visual question answering, and automated reporting — but none of that composition has been independently confirmed here, and the broader claim that Nemotron is a language-model family serving as the LLM component across NVIDIA’s blueprint architectures is likewise unverified. Both should be treated as open questions rather than background facts.
What can be said without overreach is narrower: the blueprint is positioned as a video search and summarization reference architecture. Its "verified alerts" framing borders on security-adjacent surveillance use cases, but that is not the same as it being a cybersecurity reference stack, and the sources reviewed do not make it one.
Offence is in scope too: penetration testing, bug hunting and automated attack-chain planning
The agentic security repositories are not exclusively defensive. Projects such as a cybersecurity expert agents collection and another agent project in the same vein present capabilities spanning penetration testing, bug hunting, automated attack-chain planning, and adaptive defense decision-making for attack-and-defense exercises. (Evidence level: project self-descriptions; capability claims of this kind are especially hard to take at face value without a demonstration, and no evaluation of their effectiveness was located.)
Offensive capability claims deserve more scepticism than defensive ones, not less. "Automated attack-chain planning" is easy to write in a README and hard to demonstrate against a realistic target. Readers evaluating anything in this category should ask what it was tested against before asking what it can do.
Where the adaptation really lives: behavioral memory, forensic logging and belief lifecycles
"Adaptive" is the word doing the most work across this whole landscape, and it is the least examined. A useful test is where a system keeps state between incidents.
The ACIS framework describes behavioral memory tracking and forensic logging as components sitting alongside structured detection and adaptive response escalation. (Evidence level: the project’s own repository description; not independently verified.) Separately, an adaptive belief ecology system frames the same problem more explicitly, as beliefs that have lifecycles — formed, reinforced, and retired — rather than a memory store that only accumulates.
The distinction is the practically important one: a system that only appends to memory becomes slower and more confidently wrong over time. Whether any of these projects handle belief retirement well is not something the available evidence answers.
The same rule one layer up: adaptive retrieval routing instead of always retrieving
The pattern recurs in the retrieval layer, where "adaptive" has a more concrete and more testable meaning: deciding whether to retrieve at all. An agentic adaptive RAG implementation and a write-up on building an adaptive retrieval router for agentic systems both take the position that routing the query — to vector search, to a structured source, or to nothing — beats unconditionally embedding and searching.
The security parallel is direct, and it is the same shape as the Isolation Forest observation: the adaptive part is a cheap routing decision in front of an expensive model call, not the model call itself.
Containing an agent that writes to production: cryptographic signatures, kernel sandboxing and semantic gateways
Once an agent is permitted to take response actions, the containment question stops being theoretical. A post on Google’s developer blog on building zero-trust AI agents with the Agent Development Kit argues that agents mutating production state should be constrained by infrastructure-level controls — cryptographic signatures on database writes, kernel-level sandboxing such as gVisor for dynamically generated code, and deterministic semantic gateways validating input and output — rather than by system prompt instructions. (Evidence level: a recommendation published on a vendor’s developer blog, advocating that vendor’s tooling; the reasoning is checkable but the approach’s effectiveness in deployment is not corroborated by independent sources here.)
The underlying argument holds up regardless of the vendor framing: a system prompt is a request, and a signature check is an enforcement point. A security response agent with write access to firewall rules is exactly the case where that difference decides the blast radius. This is the same boundary-versus-permission problem examined in an earlier piece on solo-built AI operators and the permissions bug underneath them.
Checking the result: adaptive black-box probes, behavioral evaluations and what the commercial insider-risk platforms claim to cover
Testing an adaptive system is its own problem, and two distinct answers appear in the sources.
The first is adversarial probing from outside. Slowave, discussed in a Hacker News thread and associated with Fabraix, is presented as an autonomous multi-turn adaptive testing harness that probes deployed agents in black-box fashion for logic bugs, instruction-following failures, and security failures including jailbreaks, prompt injection, and tool hijacking. (Evidence level: project and vendor self-description plus community discussion; no independent assessment of its coverage or false-positive rate was found.)
The second is testing from inside. A post on the anatomy of harness engineering for AI coding agents recommends behavioral evaluations — fast, local, unit-style tests that assert on discrete intermediate actions, such as whether a specific tool was called or a specific file modified — running alongside end-to-end benchmarks, so that prompt edits and model upgrades can be iterated on without silent regressions. (Evidence level: a vendor developer-blog recommendation; the practice is described, not measured.)
On the commercial side, DTEX Systems appears in this landscape as a vendor whose risk-adaptive insider risk management platform, described as comprising DTEX InTERCEPT and a Platform v7, is said to unify insider threat detection, data loss prevention, user activity monitoring, and coverage of AI and agentic risk. (Evidence level: a third-party directory listing of the company’s API presence; product scope and version details here are unverified against the vendor’s own current documentation and may be out of date.) The relevant observation is only that the commercial category exists and claims agentic risk coverage — what that coverage amounts to is open.
Developer takeaway: which part of your stack is actually doing the adapting
The most durable point across this survey is one no single source states, and it is offered as analysis rather than fact: in the designs described here, the adaptive behaviour tends to live in cheap, deterministic, testable components — an Isolation Forest scoring events, a router deciding whether to retrieve, a signature check gating a write, a belief entry aging out — while the language model supplies interpretation and sequencing around them.
If that reading is right, three questions are worth asking of any agentic security stack under evaluation:
- Does the detector call a model? If the numerical anomaly judgment goes through an LLM, the per-event cost and the failure mode both change substantially, and regression-testing a threshold stops being straightforward.
- What retires? A memory that only grows is not adaptation. Ask what causes a stored belief, a rule, or a baseline to be dropped.
- Is the containment boundary enforced or requested? If the only thing stopping a response agent from a destructive action is instruction text, the boundary is advisory.
None of this is settled. Every architecture named above is known only through its authors’ own description, the offensive capability claims are unevaluated, and the Nemotron blueprint composition remains an open question rather than a documented fact. The useful follow-up is not another survey but a measurement: take one of these open-source systems, run it against a recorded event stream, and report what the detection stage actually costs per event and how often it is right. That work has not been done here.