The Intersection of Cybersecurity and Artificial Intelligence: Navigating the Future of Digital Defense

The most useful question about AI in cybersecurity is not whether it can replace a security team. It is which task it can improve, under which conditions, and what happens when it fails. A plausible summary or a fast recommendation is valuable only if it helps the organisation make a better decision.

Digital defence deserves its own treatment. Assisting a security workflow is a different decision from authorising a military action. The relevant evidence concerns the service being protected, the analyst’s workflow and the permissions given to the tool.

Start with a task and a baseline

Possible uses include organising alerts, retrieving relevant documentation and drafting an incident summary for review. These are proposed use cases, not claims that a particular system has achieved a measured improvement. Each should be compared with the organisation’s current process and a competent non-AI alternative.

NIST’s Cybersecurity Framework 2.0 groups outcomes under Govern, Identify, Protect, Detect, Respond and Recover. That framework helps place a proposed tool within a security programme; it does not certify the effectiveness of an AI product.¹

For an alert-triage pilot, I would measure missed important alerts, unnecessary escalation, review time and the analyst’s ability to inspect the evidence. Faster handling is not an improvement if important incidents are more easily overlooked. A polished summary should identify the records supporting it and distinguish observation from inference.

The model’s inputs can become a security boundary

Defenders may ask an assistant to read logs, tickets or externally supplied material. The system must not treat every instruction found in that material as an authorised request. The organisation needs a clear distinction between information to analyse and instructions permitted to control the workflow.

NIST’s adversarial-machine-learning taxonomy identifies several kinds of attack, including poisoning, evasion, privacy and abuse. It is a vocabulary for examining threats, rather than evidence that one mitigation eliminates them.²

My recommendation is to test the actual data path. Which sources can influence the output? Who can modify them? Can the assistant reveal information to an inappropriate recipient or request an action outside the analyst’s authority? A model-only accuracy test will not answer all of these deployment questions.

Assistance should not silently acquire authority

An assistant allowed to suggest containment has a different risk profile from one allowed to execute it. Disabling an account, isolating a host or changing access may interrupt a legitimate service. Those actions need explicit permissions, evidence and a way to reverse mistakes.

NIST’s zero-trust architecture rejects implicit trust based solely on location or ownership. Applied here as a design principle, that means an AI-related component should not receive broad authority merely because it sits inside the organisation’s network.³

Begin with constrained access and reviewable recommendations. If a later pilot adds actions, specify which actions, on whose authority, under what conditions and with which logs. I would require escalation when uncertainty is consequential, rather than rely on an assistant’s confidence in its own prose.

Recovery is part of the evaluation

A security team should be able to operate when the assistant is unavailable, misleading or compromised. Maintain accessible documentation, ordinary escalation routes and the ability to revoke the tool’s access. These are proposed controls, not proof that a product is resilient.

Exercises should include a plausible but wrong recommendation and a failure of a connected dependency. Observe whether the team can identify the problem and continue its work. This evaluates the workflow and its people as well as the software.

Earn the next permission

AI can earn a place in digital defence by producing inspectable improvements on bounded tasks. Expansion should follow evidence from those tasks, with limitations carried forward rather than forgotten.

The strongest programme will be able to explain both where AI helps and where ordinary tools or human judgment remain preferable. That is a more defensible future than a promise that intelligent automation will anticipate every attack.

Sources and notes

1. NIST, The NIST Cybersecurity Framework 2.0 (February 2024). An outcomes framework, not evidence that a particular AI product improves security. ↩
2. NIST, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, AI 100-2e2025 (March 2025). Threat categories include poisoning, evasion, privacy and abuse attacks. ↩
3. NIST, Zero Trust Architecture, SP 800-207 (August 2020). Access decisions should not rely on implicit trust from network location or ownership. ↩