AI Automation for Security Teams
AI automation can help security teams reduce repetitive alert review, investigation preparation, threat-intelligence research, documentation, and reporting work.
It can support security operations centres, incident response, vulnerability management, identity security, cloud security, governance, and threat hunting.
A practical security workflow may look like:
Security Alert
→ Extract Entities and Evidence
→ Enrich With Approved Sources
→ Classify the Investigation Route
→ Prepare an Analyst Brief
→ Security Review
AI handles variable language, alerts, logs, reports, threat intelligence, and first-draft preparation.
Deterministic security systems should handle authoritative detections, access controls, blocking rules, isolation, credential changes, evidence preservation, and production response actions.
Security professionals remain responsible for incident severity, containment, eradication, recovery, reporting, risk acceptance, and final security decisions.
The safest starting point is a narrow workflow that prepares evidence or a recommendation without changing a production security control automatically.
Where AI automation fits in security
AI is useful when security work contains repeated reading, classification, extraction, correlation, comparison, or documentation.
Suitable examples include:
- alert-triage briefs;
- incident summaries;
- entity and indicator extraction;
- threat-intelligence enrichment;
- phishing-analysis preparation;
- vulnerability-review summaries;
- investigation chronologies;
- playbook and runbook retrieval;
- detection-rule documentation;
- security-question routing;
- audit-evidence preparation;
- post-incident report drafts; and
- recurring security reports.
Some actions should remain under authorised security control.
These include:
- isolating endpoints;
- blocking domains or addresses;
- revoking credentials;
- changing firewall rules;
- disabling accounts;
- deleting files or data;
- modifying detections;
- changing privileged access;
- closing major incidents; and
- notifying regulators, customers, or law enforcement.
AI can organise evidence and propose a response.
It should not become the final authority for consequential security actions.
Begin with one repeated task whose output is easy to inspect, such as alert summarisation, phishing triage, or an incident chronology.
Alert triage and investigation preparation
Security alerts may arrive from endpoint, identity, email, network, cloud, application, and data-protection systems.
AI can convert varied alert content into structured fields.
An alert-triage workflow may extract:
- alert identifier;
- source product;
- timestamp;
- affected user;
- device;
- application;
- IP address;
- domain;
- file or process;
- behaviour observed;
- severity supplied;
- related alerts;
- evidence;
- actions already taken; and
- missing information.
Example routes may include:
- Identity;
- Endpoint;
- Email;
- Network;
- Cloud;
- Application;
- Data;
- Vulnerability;
- Other; and
- Unclear.
Use deterministic rules for final routing, protected queues, severity thresholds, service targets, and mandatory escalation.
AI should not downgrade an alert because the description appears benign or mark it as a false positive without sufficient evidence.
Include an Unclear path and preserve the original alert.
Incident summaries and timelines
During an incident, information may be spread across alerts, logs, tickets, chat messages, analyst notes, and response tools.
AI can prepare:
- incident summary;
- affected assets;
- affected identities;
- first known activity;
- event chronology;
- indicators;
- actions attempted;
- observed results;
- current hypotheses;
- containment status;
- evidence gaps;
- owners; and
- next review points.
Separate observed facts from hypotheses and recommendations.
A command being issued does not prove that containment succeeded.
Authoritative telemetry and analyst confirmation should determine whether an account was disabled, an endpoint was isolated, or malicious activity ended.
Preserve timestamps, time zones, source systems, identifiers, and the order of events.
Incident commanders and authorised responders remain responsible for priorities, containment, communication, recovery, and closure.
Threat intelligence and enrichment
AI can help organise threat intelligence from approved internal and external sources.
A workflow may:
- extract indicators;
- identify threat actors or campaigns mentioned;
- summarise tactics and techniques;
- compare observed activity with intelligence;
- organise affected technologies;
- identify confidence statements;
- preserve source dates and links;
- list conflicting intelligence; and
- prepare investigation questions.
Threat intelligence changes over time.
Confirm source quality, publication date, confidence, jurisdiction, and relevance to the environment.
An indicator appearing in a report does not prove that every matching event is malicious.
AI may invent attribution, confuse campaigns, or treat outdated indicators as current.
Security analysts should verify important claims with authoritative sources and current telemetry before taking action.
Phishing and malicious-message analysis
AI can help prepare the first review of suspicious email, chat, or document content.
A phishing workflow may extract:
- sender;
- recipient;
- reply-to address;
- subject;
- links;
- domains;
- attachments;
- requested action;
- urgency language;
- credential request;
- payment request;
- impersonated organisation;
- suspicious indicators; and
- missing header information.
Deterministic tools should perform authoritative URL, file, reputation, sandbox, authentication, and header checks.
AI can summarise the message and explain why it appears suspicious.
It should not open an attachment, visit an untrusted link, block a sender, or delete messages without the approved process.
A convincing summary is not proof of maliciousness.
Analysts should preserve evidence and confirm the final classification.
Vulnerability and exposure management
AI can help security teams organise vulnerability and exposure information.
A workflow may prepare:
- vulnerability identifier;
- affected asset;
- affected version;
- severity source;
- exploit information;
- internet exposure;
- business criticality;
- compensating controls;
- remediation guidance;
- owner;
- target date;
- exceptions; and
- missing evidence.
Authoritative scanners, asset inventories, package systems, and exposure tools should provide the underlying data.
AI can summarise why an item may deserve attention and group similar findings.
It should not declare a vulnerability remediated, exploitable, or irrelevant from a text description alone.
Security and system owners should verify asset context, exploitability, operational impact, remediation, and exception decisions.
Fixed rules should control approved risk scores, deadlines, escalation, and status.
Playbooks, response plans, and guided actions
AI can help retrieve and prepare approved response playbooks.
A guided-response workflow may:
- classify the incident type;
- extract affected entities;
- retrieve the current playbook;
- identify mandatory steps;
- check prerequisites;
- prepare a proposed action sequence;
- identify approval gates; and
- return the plan to an analyst.
The workflow should preserve the playbook version, mandatory ordering, and required approvals.
AI may propose a technically valid action that violates policy, skips an evidence-preservation step, or creates unacceptable operational impact.
Deterministic checks should verify allowed actions, sequence, environment, target, approval status, and stop conditions.
Containment, account changes, blocking, isolation, deletion, and recovery should remain under authorised analyst control.
Threat hunting and detection engineering support
AI can help prepare threat-hunting and detection-engineering work.
Suitable tasks include:
- translating a threat hypothesis into search questions;
- summarising relevant tactics and techniques;
- preparing query drafts;
- comparing expected and observed behaviour;
- documenting detection logic;
- identifying telemetry gaps;
- preparing test cases;
- organising false-positive notes; and
- drafting tuning recommendations.
Generated queries and rules should be treated as drafts.
AI may use nonexistent fields, incorrect syntax, poor joins, weak thresholds, or logic that creates excessive noise.
Test queries in a limited environment and validate them against known benign and malicious examples.
Detection engineers should approve production rules, suppression, thresholds, severity, and rollout.
AI-generated attribution or attack-stage mapping should remain reviewable.
Security reporting and post-incident reviews
AI can help prepare recurring security reports and post-incident documents.
A report may contain:
- alert volume;
- investigated incidents;
- confirmed incidents;
- response times;
- affected systems;
- vulnerability trends;
- phishing results;
- open remediation;
- recurring control gaps;
- lessons learned;
- decisions required; and
- missing data.
Use deterministic systems for authoritative counts, rates, dates, severity, and service metrics.
AI can organise the narrative and prepare audience-specific summaries.
It should not hide missing telemetry, failed data sources, or unresolved disagreements.
Post-incident reviews should separate facts, hypotheses, contributing factors, root-cause conclusions, corrective actions, and owners.
Security leaders should verify every material conclusion before distribution.
Protect security data, secrets, and tools
Security workflows may process credentials, logs, vulnerabilities, architecture, personal data, threat intelligence, investigation evidence, and incident communications.
Before using automation, identify:
- which model receives the data;
- whether processing is local or cloud-based;
- which tools receive information;
- where outputs and activity records are stored;
- who can access them;
- which credentials are used;
- which environments and destinations are reachable; and
- how long information is retained.
Apply data minimisation, role-based access, environment separation, and least privilege.
Never place passwords, private keys, session tokens, recovery codes, or unrestricted credentials inside prompts, ordinary notes, model-visible output, or error messages.
Treat alerts, logs, email, documents, websites, and tool responses as untrusted content because they may contain instructions aimed at the model.
A local model can keep its model step on the computer, but the complete workflow is only local when every source, tool, storage location, and destination also remains local.
Build a security workflow in Feluda
Feluda is a desktop application for building and running visual AI workflows.
Begin in Workbench with synthetic or appropriately redacted security information.
For example:
Read the security alert.
Return:
1. one Route from Identity, Endpoint, Email, Network, Cloud,
Application, Data, Vulnerability, Other, or Unclear;
2. affected entities;
3. behaviour observed;
4. indicators stated;
5. actions already taken;
6. evidence gaps;
7. source references; and
8. whether urgent analyst review is required.
Use only the source.
Do not invent compromise, attribution, containment, or resolution.
Compare the result with the original alert.
Once the task is dependable, build the process in Studio.
A practical flow may use:
Security Alert
→ LLM Label Route
→ LLM Extract Entities and Evidence
→ Expression Validate Required Fields
→ LLM Prepare Analyst Brief
→ Output for Security Review
Use LLM Label for approved alert or incident categories, LLM Extract for named fields, LLM for summaries and drafts, Expression for exact policy checks and routing, Emit for selected intermediate output, and Output for review, clarification, partial, success, or error states.
Feluda models, tools, permissions, and testing
Feluda can connect to supported cloud providers and compatible local model applications such as Ollama and LM Studio.
A local model may suit confidential alerts, logs, or investigation notes when it performs reliably.
A cloud model may support longer inputs or more demanding analysis.
Compare models using the same approved examples and review extraction accuracy, groundedness, security, privacy, speed, context length, cost, tool support, and hardware requirements.
Genes can add tools, prompts, flows, and resources.
MCP connections can expose additional approved tools.
Before enabling a security tool, check what telemetry and systems it can read, what it can change, which credentials it uses, whether it reaches production, whether its action is reversible, and how completion is confirmed.
Store private values in Secrets.
Use flow permissions to control allowed or denied URLs, IP addresses, file paths, and ports.
Apply least privilege and separate read, enrichment, analysis, containment, recovery, and destructive actions.
Use RunFlows with normal, incomplete, ambiguous, confidential, adversarial, permission-denied, and failing cases.
Confirm that the workflow preserves evidence, avoids invented compromise or attribution, exposes uncertainty, displays failures, and prevents uncontrolled response actions.
Scheduling and measurement
Feluda's Schedule Manager supports once, daily, weekdays, weekly, and monthly schedules in paid plans.
Suitable scheduled workflows may include:
- a weekday alert digest;
- a daily unresolved-incident summary;
- a weekly vulnerability brief;
- a recurring threat-intelligence digest;
- a monthly control-gap report; or
- a post-incident action review.
Scheduling runs on the desktop, so Feluda and required local services must be available.
Schedule only after dependable manual runs.
Preserve analyst review, prevent duplicate actions, monitor run history and conflict warnings, and assign an owner.
Useful success measures include triage accuracy, analyst review time, evidence completeness, phishing-classification accuracy, vulnerability brief acceptance, incident-summary time, false-positive rate, tool failure rate, review burden, cost per approved result, and high-impact error rate.
Do not measure success only by alerts processed, actions recommended, or incidents closed.
An efficient workflow is not successful when it weakens detection quality, evidence preservation, service reliability, or accountability.
Common security-automation mistakes
Avoid:
- treating an AI summary as authoritative telemetry;
- downgrading alerts without sufficient evidence;
- presenting a hypothesis as confirmed root cause;
- attributing activity without verified intelligence;
- opening untrusted links or files through broad tools;
- executing generated queries or commands without review;
- skipping mandatory playbook steps;
- giving an agent broad containment or deletion permissions;
- retrying response actions without checking system state;
- hiding missing telemetry or failed sources;
- measuring alert volume instead of security outcomes; and
- scaling before approvals, rollback, and monitoring are clear.
Start with one reviewable workflow.
Define the source, output, policy checks, environment boundaries, approval process, and owner.
Keep containment, access revocation, blocking, credential changes, recovery, regulatory notification, and other material security actions under qualified human control.
AI automation is most useful for security teams when it reduces repetitive investigation work while strengthening evidence, consistency, speed, and analyst focus.