Skip to content
AI security

AI in IT Infrastructure and Cybersecurity: Where It Helps and Where It Fails

By Sudhir 7 min read

AI is already inside infrastructure and security products. Sometimes it means a statistical anomaly model. Sometimes it means a language model summarizing an alert. Vendors often put both behind the same label.

That makes “Does this tool use AI?” a weak evaluation question. Ask which decision the system makes, which data it uses, how often it is wrong, and what happens after the output.

This is an evaluation framework, not a production comparison of the named products. I have not run most of them in production. Product names near the end show where the categories appear, not which vendor wins.

AI in IT Infrastructure and Cybersecurity

Four jobs that should not be confused

AI-labelled infrastructure and security features usually perform one of four jobs.

Classification assigns an event to a known category. Endpoint protection may classify a file or process as malicious. Email security may classify a message as phishing.

Anomaly detection finds behaviour that differs from a baseline. This can expose unusual authentication, network, or resource activity, but unusual does not automatically mean malicious.

Correlation groups related events. An XDR platform may connect a suspicious login, endpoint process, and outbound connection into one investigation.

Generation produces text or code. A security assistant may summarize an incident, translate a natural-language question into a query, or draft a detection rule.

Each job fails differently. A classifier can miss a threat. An anomaly model can overwhelm a team with normal but rare behaviour. Correlation can join unrelated events. A language model can invent facts or unsafe commands.

Infrastructure operations

AIOps products ingest metrics, logs, traces, topology, and change data to identify incidents or likely causes. The useful cases are usually narrow:

  • Grouping many alerts caused by one outage
  • Detecting a deviation in resource or service behaviour
  • Connecting an incident to a recent deployment or configuration change
  • Forecasting capacity from historical demand

These systems depend on service ownership, timestamps, topology, and change records. If those inputs are incomplete, the output may be a confident description of the wrong cause.

Automation also changes the risk. Restarting a failed stateless service may be safe. Changing a firewall rule or deleting a resource based on a model’s suggestion needs stronger validation and a rollback path.

Threat detection

Machine learning has supported malware detection, user and entity behaviour analytics, email filtering, and network detection for years. It can evaluate more signals than a simple signature and may detect variants that have no exact known hash.

It does not make signatures or rules obsolete. Known malicious infrastructure, file hashes, protocol violations, and explicit policy checks remain fast and explainable. A capable detection stack combines deterministic indicators with behavioural models.

For any detection feature, ask for results on your own data. Measure false positives, missed test cases, time to investigate, and the context available to the analyst. A high detection rate in a vendor benchmark does not show whether the system can distinguish administrators, scanners, batch jobs, and attackers in your environment.

Investigation assistants

Language models are useful when they reduce translation work. They can summarize several alerts, explain an unfamiliar command, draft a query, or turn investigation notes into a report.

The risk is that fluent text looks more certain than the evidence. A summary may merge events incorrectly or invent a reason that does not appear in the logs. Analysts should be able to open every supporting event and rerun every generated query.

Treat generated content as a draft. Do not let an assistant close an incident, change severity, or present an unsupported conclusion as fact without review.

A test incident

Suppose an identity alert reports an impossible-travel sign-in, an endpoint alert shows PowerShell, and the firewall records an outbound connection from the same laptop.

An assistant may summarize those events as account compromise followed by malware execution. That is a hypothesis, not a finding. The analyst still needs to check whether the sign-ins used the same session, whether PowerShell ran before or after the login, which command executed, who owned the destination IP, and whether the timestamps use the same clock.

The useful output links each sentence to the source event and exposes the generated query. The dangerous output turns three nearby alerts into a confident attack narrative with no trace back to evidence.

Automated response

Automation can shorten containment time. It can also disable the wrong account or isolate a critical server.

Match the approval requirement to the blast radius. Adding a hash to a temporary block list may be reversible and narrow. Rotating credentials, blocking a network range, or deleting a cloud resource needs higher confidence and often a person in the loop.

A response workflow should record the triggering evidence, decision, action, result, and rollback. If the model’s role cannot be reconstructed afterward, the automation is not ready for production.

How to evaluate a product

Start with one expensive or unreliable task, not an AI feature list. Alert triage is a better problem statement than “modernize the SOC with AI.”

During a proof of concept:

  1. Use representative logs and known benign noise.
  2. Include incidents the current process misses and incidents it handles well.
  3. Measure analyst time, false positives, missed detections, and correction effort.
  4. Require links from summaries to source evidence.
  5. Test unavailable or malformed data.
  6. Record every integration and tuning step.
  7. Test rollback for any automated action.

Compare the result with the current process. Saving five minutes on a summary does not justify a product if an analyst spends ten minutes checking invented details.

Questions for the vendor

The answers should be specific to the feature you are buying:

  • What model or method makes this decision?
  • Is customer data used for training, and can that use be disabled?
  • Where is data processed and retained?
  • Which evidence supports each result?
  • How does the system handle missing or delayed telemetry?
  • Can the team tune, override, and audit the output?
  • Which actions can the system take without approval?
  • How is performance measured after deployment?

“Proprietary AI” is not a useful answer to any of these questions.

Where the categories appear

The market changes too quickly for a permanent ranking. These examples come from product material and public documentation, not a controlled comparison.

Microsoft Security Copilot can assist investigations inside the Microsoft security stack. Google Threat Intelligence with Gemini can help analysts work through threat intelligence and malware information. SentinelOne Purple AI provides a natural-language layer for hunting within its platform. VirusTotal Code Insight can summarize submitted scripts for triage.

EDR and XDR platforms from vendors such as CrowdStrike, SentinelOne, and Microsoft use statistical and behavioural methods in detection and correlation. Network-focused platforms such as Vectra and Darktrace apply models to network and identity activity.

The integration boundary matters more than the demo. A natural-language query is useful only if the underlying telemetry is complete and the analyst can inspect the generated query and results.

The work I would fund first

Before buying another AI security product, I would fix the data feeding the tools already deployed.

Asset inventory, log coverage, identity ownership, time synchronization, alert routing, and incident labels are unglamorous. They are also what allow a model to connect an event to the right system and allow an analyst to verify the answer.

AI can reduce parts of the workload. It cannot tell you who owns a server that never entered the inventory or reconstruct logs that were never collected. If the current process cannot produce reliable evidence, adding a fluent summary will only make the uncertainty easier to read.

Continue reading