What an AI Agent for Cyber Security Actually Is
An AI agent for cyber security, as the phrase is used across current security tooling, is a large language model (LLM) connected to security tools, given a goal, and permitted to select its own next steps within limits a human defines. That is the sense this article uses throughout, and it is worth stating narrowly, because "AI agent" is an older and broader term in computer science: rule-based agents, planning agents, and multi-agent simulations predate LLMs entirely and are not what security vendors are selling under the label today.
Autonomous step selection is the most visible difference, but it is not the whole definition. A useful working definition combines four properties: control flow (who decides the next step — the human or the system), tool access (whether the system can act on the world or only produce text), persistence (whether state survives a single exchange), and autonomy bounds (which actions run without confirmation). Systems differ on each axis independently, which is why the categories below blur in practice.
Agent, chatbot, copilot, and SOAR playbook compared
| Control flow | Tool access | Persistence | Typical autonomy | |
|---|---|---|---|---|
| Chatbot | Human drives each turn | Usually none, or narrow retrieval | Varies — many retain conversation state or long-term memory | Answers only |
| Copilot | Human drives; system suggests | Read-heavy, inside a host application | Session-scoped, sometimes workspace-scoped | Suggest and draft |
| SOAR playbook | Predefined branch logic | Broad, by design | Case and workflow state | Executes authored steps |
| LLM agent | Model selects next step | Read and, if granted, write | Session plus optional long-term memory | Configurable, up to acting within a set blast radius |
A chatbot is a conversational interface. It is not inherently stateless — many retain conversation history, and some retain memory across sessions — but the human supplies the goal and drives each turn.
A copilot is embedded assistance. It sits in a SIEM or EDR console, drafts a query, summarizes an alert, and waits for acceptance. The human remains the controller of the loop.
A SOAR playbook is authored automation. Security orchestration, automation and response tools execute steps someone wrote in advance: if alert type equals X, enrich with Y, then open a ticket. Playbooks are far more predictable than model-driven systems, though not literally deterministic — they depend on external data sources, timing, and integrations that change. Their real limitation is coverage: a playbook handles the paths its author anticipated, and unanticipated inputs fall through to a human or to an error branch.
An agent replaces some of that authored branch logic with model-generated decisions. It can approach a case the playbook author never imagined, and it can also take a path nobody reviewed. Predictability is the property being traded away, and most of both the promise and the risk follows from that trade.
The five components: model, tools, memory, orchestration loop, approval gates
Treat any agent as a bill of materials. Each layer has a different risk profile and a different owner.
- Model. The LLM that reasons and generates. Hosted API or self-hosted weights. Determines quality, cost, latency, and where your data physically goes.
- Tools. The functions the agent may call — tool calling, sometimes called function calling. Query the SIEM, look up a hash, isolate a host, open a ticket. This layer is where an agent stops being a text generator and becomes an actor with permissions.
- Memory. Short-term context plus anything persistent: prior cases, retrieved documents via retrieval-augmented generation (RAG), a vector store of internal runbooks. Memory is what makes an agent useful across sessions and what makes it poisonable.
- Orchestration loop. The controller that decides when to call a tool, when to retry, when to stop, and what to do when a tool errors. Loop design determines whether a bad step is caught or compounded.
- Approval gates. The human-in-the-loop checkpoints. Which actions execute freely, which require confirmation, which are forbidden outright.
If a product's documentation does not describe all five layers, you are evaluating a demo rather than a system you can reason about.
Levels of autonomy: suggest, draft, act-with-approval, act-autonomously
Grading a deployment is more productive than arguing about whether something "is" an agent:
- Suggest — the agent proposes an interpretation; a human does the work.
- Draft — the agent produces an artifact (a detection rule, an incident summary) that a human edits and ships.
- Act with approval — the agent proposes a specific action with parameters; a human confirms.
- Act autonomously — the agent executes within a defined blast radius, and humans review after the fact.
NewsForge has not identified an independent, published survey establishing how deployments are distributed across these four tiers, so this article makes no claim about which tier is most common. The grading is offered as an evaluation tool: ask a vendor or an internal team which tier applies, for which alert classes, and the conversation becomes concrete.
Why the term 'autonomous SOC' is doing a lot of work
"Autonomous SOC" is a marketing frame. Vendor case studies are vendor claims and should be read as such: the brand rule at NewsForge is that a supplier's own material is acceptable evidence for what a product is designed to do, and not for how well it works. This article does not assert that no product can run a security operations center without analysts, and it does not assert that any product can. What it recommends is a specific line of questioning: which of the four autonomy levels is shipping, for which alert classes, what the agent does with cases it declines, and what independent evaluation — not vendor benchmark — supports the answer. Absent an independent evaluation you can read, the honest position is that the claim is untested rather than disproven.
Where Security Agents Are Being Pointed
A caveat belongs at the top of this section: the workflows below are described from product documentation and practitioner accounts of what these systems are built to do. NewsForge has not located independent, reproducible efficacy evaluations for these workflows, and none is asserted here. Read this as a map of where the technology is being applied, not as a performance ranking.
The structural pattern is that agents fit most comfortably where the task is read a lot of context, produce structured text, and touch nothing irreversible. They fit least comfortably where the task requires ground truth the model does not hold.
Alert triage and enrichment in the SOC. Pull an alert, gather surrounding context — asset owner, recent authentications, EDR/XDR telemetry, reputation lookups — and produce a summarized case with a proposed disposition. This is the most commonly marketed use case, because the inputs are machine-readable and the output is a recommendation rather than an action.
Phishing and email report handling. User-reported mail is high-volume and repetitive. An agent can detonate links in a sandbox via tools, compare against known campaigns, and draft a response to the reporter. Note the failure mode built into the task: a phishing email is attacker-controlled text that your agent reads by design, which is exactly the indirect prompt injection scenario covered below.
Threat intel summarization and correlation. Condensing advisories, mapping activity to MITRE ATT&CK techniques, and flagging what is relevant to a given stack. Mapping to ATT&CK is interpretive work, so agent-assigned technique IDs are best treated as a first pass an analyst confirms.
Vulnerability triage and patch prioritization. Cross-referencing a CVE against asset inventory, exposure, and compensating controls to answer "does this matter to us this week?" Assembling that argument is a text-and-lookup task. The exploitability judgment is not, particularly for actively exploited chains of the kind covered in NewsForge's advisory on a critical WordPress RCE chain.
Log and detection-rule authoring. Drafting queries and detection logic from a described behavior. Agents accelerate the blank page. They do not validate a rule against your data; false-positive rates only appear when you test.
Incident documentation and reporting. Timelines, executive summaries, and after-action drafts assembled from ticket and chat history. The least glamorous application, and the one with the most forgiving failure mode, because errors surface in review rather than in production.
What agents are not good at
Four categories consistently sit outside the comfortable zone, and readers evaluating a pilot should treat claims in these areas with extra scrutiny:
- Ground truth the model cannot look up. Whether a binary is malicious in your environment, whether a login was really the user, whether an exception was approved.
- End-to-end autonomous investigation and containment across a heterogeneous environment. Claims in this direction rest largely on vendor material; NewsForge has not identified independent evaluations supporting them.
- Calibrated uncertainty. Models tend to produce fluent output regardless of confidence, which is why "escalates when unsure" belongs on an evaluation checklist.
- Anything irreversible. Not because agents are uniquely careless, but because the cost of a wrong step is asymmetric and the systems are nondeterministic.
The Offensive Side: Agents as Attacker Infrastructure
The same architecture is available to attackers, but the evidentiary bar matters. NewsForge has not verified the documented incidents the brief required, so no campaign, threat group, or vendor report is named. What follows is structural capability analysis, not reporting of documented attacks, and it carries an open evidence gap.
Reconnaissance, target profiling, and lure generation. The capabilities that let an agent assemble context about an alert let one assemble public information about an organization and its staff, and generate contextually specific pretexts. It is often argued that this weakens two heuristics defenders historically taught users — clumsy language and generic framing. That is a plausible consequence rather than a measured one, and other indicators, such as sender infrastructure, payment-change requests, and urgency framing, are unaffected. Social engineering and the human element in cybercrime losses are covered separately in NewsForge's analysis of the FBI's 2025 report; take specific figures from that report directly.
Agentic exploitation research and where it stalls. Agents can assist with reconnaissance, code reading, and script assembly, but reliable end-to-end exploitation of hardened, unfamiliar targets is harder. No verified source supports a numeric state-of-the-art claim here.
Lowering the skill floor. The economics of packaged criminal tooling are documented in NewsForge's reporting on subscription cybercrime and the commercialization of malice. Agent architectures fit that distribution model in principle, by extending competence to buyers who lack it. Whether this has produced a measurable shift in attacker capability is not established here.
Documented versus claimed. Treat provider or threat-intelligence accounts of adversarial AI misuse as self-reported unless independently corroborated. Without a named research team, publication date, and methodology, a capability claim is not a finding — a standard that applies to this article too.
The New Attack Surface: Attacking the Agent Itself
Most coverage stops at what agents do for defenders. A security agent is also a privileged, promptable system that reads untrusted input as part of its normal job.
Prompt injection through the data the agent reads
Direct prompt injection is a user instructing the model to disregard its instructions. Indirect prompt injection is the harder case: instructions hidden in content the agent ingests — an email body, a web page, a log field, a filename, a PDF attached to a ticket.
The mechanism is architectural. Instructions and data arrive in the same channel, and current models do not reliably separate "content I am analyzing" from "instructions I should follow." Mitigations exist — input filtering, privilege separation between the planning and execution stages, structured output constraints, and human confirmation before consequential tool calls — and the accurate framing supported by the public literature is that these reduce the risk rather than eliminate it.
Prompt injection appears in the OWASP Top 10 for LLM Applications, and the research literature on injection and agent security is active. This draft does not cite the specific OWASP entry number, paper titles, authors, or publication dates, because those citations must be opened and verified before they are stated. That verification is outstanding, and readers building agents should consult the OWASP project's own current documentation and the primary literature directly rather than relying on any single vendor's mitigation claims.
The practical consequence for security teams is sharp regardless: a phishing-triage agent reads attacker-authored text by design, and that is the input path to test first.
Tool and API over-permissioning
Agents are typically wired to service accounts, and service accounts drift toward broad scopes because narrow ones break workflows. An agent holding a read-write SIEM key, EDR isolation rights, and ticketing access has, in aggregate, more reach than most individual analysts. Least privilege applies per tool rather than per agent, and read-only is the sensible default for anything the agent uses to understand rather than to fix.
Memory and context poisoning
If an agent persists conclusions, an attacker who influences one case can influence later ones. Poisoning a RAG corpus or case memory — planting, for example, the assertion that a particular hash is a known-good internal build tool — creates a durable false belief that shapes future triage. Memory needs provenance on stored facts, expiry, and the ability to be audited and purged.
Supply chain risk in agent frameworks, plugins, and connectors
Agent stacks assemble quickly from open source frameworks, community plugins, and Model Context Protocol (MCP) style connectors that expose tools to models. Each connector is code executing with the agent's credentials, and in pilots it is often installed with less scrutiny than a production dependency would receive. Ordinary software supply chain hygiene applies: pinned versions, reviewed sources, and an inventory of what is installed.
Confused-deputy and privilege escalation
The confused-deputy pattern describes a low-privilege actor persuading a higher-privilege component to act on its behalf. An analyst-facing agent holding administrative tools fits that shape. The mitigation is architectural: where the platform supports it, the agent should act with the requesting user's authority rather than a standing superuser identity.
Data leakage to third-party model providers
Sending alert context to a hosted model means sending internal hostnames, user identities, source code fragments, and sometimes regulated data to an external processor. That is a contractual and jurisdictional question as much as a technical one: what is retained, for how long, whether it is used to train future models, and which legal regime governs it. Those terms sit in the provider's data processing agreement and should be read before telemetry starts flowing, not after — "we send it to the API" is a governance decision with a paper trail attached to it.
Deployment Models: Self-Hosted, Open Source, and Managed Platforms
Because the required repository, license, and maintenance verification is incomplete, no open source framework is named or assessed here. This section compares deployment models instead.
Self-hosted models and on-prem inference. Running open-weight models on your own hardware keeps telemetry inside your boundary and removes per-token API charges. It does not remove cost: it substitutes hardware, energy, depreciation, capacity planning, model updates, and staff time. Capability comparisons between hosted and open-weight models change with each release and should be made against security-relevant evaluations on your own data rather than assumed; NewsForge's coverage of releases such as Kimi K3 and the broader questions those releases raise illustrates how quickly the option set moves.
Auditability and traceability. Whether you can log every prompt, tool call, and intermediate output is an implementation property, not a property of self-hosting. Some closed platforms expose full traces; some self-hosted stacks are configured badly and expose little. Ask for the capability specifically. Note also that retaining a trace lets you reconstruct what the agent saw and did, which is what post-incident review needs; it does not guarantee that rerunning the same input reproduces the same output, because these systems are nondeterministic.
Cost, maintenance, and staffing. Self-hosting and open source shift spend from license fees to labor. Someone maintains the framework, patches dependencies, tunes prompts, and re-evaluates after every model swap. That labor line is easy to omit from a business case built on API pricing alone, and it is the one to force into the comparison before committing.
When managed is the defensible choice. Without an ML-capable engineer, evaluation harness, or production monitoring capacity, a managed platform with clear data terms is the conservative choice. It shifts operational burden, not accountability. Customers of a managed security service provider (MSSP) should likewise ask what the provider's agent does with their data.
One further caution: a project being open source means the code is inspectable. It does not mean anyone has inspected it.
How to Evaluate an AI Security Agent
Use this as a scannable checklist for buying or building.
| Area | What to ask | What a good answer looks like |
|---|---|---|
| Model provenance | Which model, which version, hosted where? | Named model and version, documented region, change notification when it updates |
| Data handling | What is sent, retained, and trained on? | Contractual retention limits, no training on customer data, deletion process |
| Tool permissions | What can the agent do, with whose identity? | Per-tool scopes, read-only default, acts as requesting user, no standing admin |
| Injection resistance | What happens with hostile text in an input? | Tested against documented cases, results shared — not "the model is instructed to ignore it" |
| Memory | What persists, and can it be audited or purged? | Provenance on every stored fact, expiry, purge tooling |
| Audit trail | Can you reconstruct a decision months later? | Full prompt, tool-call, and output logs exported to your SIEM |
| Approval gates | Which actions are gated, and can you change the thresholds? | Configurable per action class, gates enforced server-side |
| Failure behavior | What does it do when uncertain? | Escalates and says so, rather than producing a confident answer |
| Supply chain | What connectors and plugins ship with it? | Inventory, pinned versions, update policy |
| Evidence | What independent evaluation exists? | Something you can read that the vendor did not write |
Human-in-the-loop thresholds. As a working default, nothing irreversible, wide-blast-radius, or externally visible should run without approval: disabling accounts at scale, pushing firewall or EDR policy, deleting data, quarantining production hosts, or communicating with customers, regulators, or law enforcement.
Measuring value. Track mean time to triage, the proportion of alerts closed without human touch and later confirmed correct, false-positive reduction, analyst hours returned, and the review burden the agent itself creates. If analysts spend as long checking the agent as they would have spent doing the work, effort has been relocated rather than removed. Measure a baseline before deployment, or the comparison is unavailable afterward.
Red-teaming your own agent. Before production: attempt indirect injection through every untrusted input path, try to induce a tool call that should be out of scope, attempt to poison memory and confirm whether the poison persists, and verify that approval gates cannot be argued around in conversation. Zero trust principles apply to the agent as to any other identity — authenticate it, scope it, monitor it, and assume it can be compromised.
On governance and standards
Two references recur in this space: the NIST AI Risk Management Framework, useful as a structure for organizing risk work, and the OWASP Top 10 for LLM Applications, the most commonly cited catalog of LLM-specific risks. Neither is a compliance regime for autonomous action in a SOC. Exact document numbers, versions, and publication dates are omitted here pending verification against the publishers' own pages; cite them from the primary source when you reference them internally.
On regulation, this draft makes no claim about what regulators have or have not issued. A defensible statement requires a named jurisdictional and sectoral scope, primary statutory or regulator-guidance sources, and an explicit review date — research that has not been completed for this piece. What can be said without that research is narrower and still useful: rules governing automated decision-making, data protection, incident reporting, and sector-specific security controls can apply to an agent's inputs, outputs, and consequences without ever using the word "agent." Check the regimes that already bind your organization before assuming a gap exists.
What Changes for Security Jobs and Team Structure
Tasks compress before roles disappear. The most exposed work is repetitive summarization and enrichment — much of the composition of a tier-one queue. That does not translate cleanly into headcount reduction, because agent output needs review and agents need operators. NewsForge examined this at length in Will Cybersecurity Be Replaced by AI?; the short version is that judgment, adversarial reasoning, and accountability do not delegate.
New responsibilities appear. Someone owns agent operations: prompt and tool governance, permission reviews, evaluation after every model change, monitoring for drift, and an incident-response path for when the agent itself is the incident. Add a line to the IR plan for "the agent took an unauthorized action," including how to revoke its credentials quickly.
Skills worth building. Tool and permission design; evaluation and testing of nondeterministic systems; prompt injection and LLM red teaming; enough data engineering to build clean retrieval sources; and the ability to read a vendor's architecture description and identify which of the five components it is vague about.
Frequently Asked Questions
Can an AI agent replace a SOC analyst?
No evidence available to NewsForge supports that. Agents handle enrichment, summarization, and drafting, and may reduce time spent on repetitive triage. They do not carry accountability, they fail unpredictably on unfamiliar cases, and their output requires review. The plausible effect is that analysts spend less time assembling context and more on judgment, escalation, and supervising the agent.
Are AI security agents safe to give production access?
Only with narrow, explicitly scoped permissions and approval gates on irreversible actions. Start read-only. Grant write access one tool at a time, with the agent acting under the requesting user's identity rather than a standing admin account. Log every tool call to your SIEM, test injection resistance before deployment, and keep a fast path to revoke the agent's credentials.
What is the difference between agentic AI and traditional security automation?
Traditional automation such as a SOAR playbook follows steps a human authored in advance and behaves consistently across runs. An agentic system uses a language model to select its own next step, so it can approach situations nobody scripted — and can also take paths nobody reviewed. You gain coverage and lose predictability, which is why auditing and approval gates matter more.
Can small teams run an AI security agent affordably?
Possibly, but budget for more than API charges: infrastructure, staff time, evaluation, and ongoing supervision. NewsForge has not found independent total-cost studies for narrow security workloads, so treat any figure carefully. A small team with one bounded use case and firm read-only scoping is the lower-risk starting point. Managed options shift operational burden, not accountability.
Before You Deploy
If you are piloting an AI agent for cyber security, run five questions against it: Which model, hosted where, and what happens to our data? What can it actually do, and with whose identity? What does it do with hostile text in an input? Can we reconstruct any decision it made months later? And what is it forbidden to do without a human? A product that answers all five crisply is worth testing. One that cannot is worth waiting on.
For the longer argument about what this means for security careers, see our explainer on whether AI will replace cybersecurity roles. Subscribe to NewsForge for continued coverage of agentic AI and security.
