AI in Cybersecurity

What AI in cybersecurity means

AI in cybersecurity is best understood as a two-sided discipline rather than a single product category. On the defensive side, AI technologies may provide defenders with new tools for addressing security vulnerabilities and may transform cybersecurity practice. On the assurance side, organizations must govern, map, measure, and manage risks specific to AI-enabled capabilities in addition to applying the security concerns that affect ordinary software and information systems.1

The scope therefore includes the AI model or service, its training and operational data, supporting applications, hardware, interfaces, dependencies, development pipeline, deployment environment, users, and downstream outputs. The cited NIST security-and-resilience material explicitly identifies confidentiality, integrity, and availability concerns for AI systems and for their training and output data, as well as security of the underlying software and hardware. This makes AI security a lifecycle and system problem, not merely a model-testing activity.1

Why AI in cybersecurity matters

AI changes the risk conversation because it can be both an enabling technology and an attack surface. NIST describes AI security and resilience as an active research area whose challenges and potential solutions are changing rapidly. The same material notes that AI technologies may enhance the capabilities of people seeking to target organizations and individuals through information-technology and operational-technology attacks, even as AI may help defenders address vulnerabilities.1

AI risk should be considered alongside financial, cybersecurity, reputational, and privacy risk rather than managed in an isolated program. NIST CSF 2.0 states that cybersecurity and privacy risk-management considerations apply to the design, development, deployment, evaluation, and use of AI systems. Treating AI risks within enterprise risk management can produce a more integrated outcome and organizational efficiencies, while helping executives connect cybersecurity decisions with broader business priorities.3

The practical implication is proportionality. A team should not assume that every AI use case has the same exposure or requires the same controls. It should define the system’s mission, users, data, dependencies, decisions, and consequences; identify the risks that matter for that context; and choose safeguards that reflect organizational priorities and available resources. NIST CSF 2.0 is intentionally sector-, country-, and technology-neutral, so organizations retain flexibility to address their unique risks, technologies, and mission considerations.3

A practical operating workflow

A useful enterprise workflow begins with governance and ends with measured improvement. First, establish accountability for the AI capability and define the business or security outcome it is intended to support. Next, create a scoped current profile: document relevant policies, risk priorities, resources, enterprise risk information, business-impact information, requirements, standards, practices, tools, safeguards, and work roles. Then define a target profile, analyze gaps, and create an action plan. NIST CSF 2.0 describes organizational profiles in these terms and permits multiple profiles with different scopes.3

1. Define the AI use case, mission, scope, users, data flows, dependencies, and accountable owners.
2. Identify security, privacy, operational, reputational, and other enterprise risks across design, development, deployment, evaluation, and use.
3. Record a current profile of relevant outcomes, practices, safeguards, requirements, roles, and assumptions.
4. Set a target profile and prioritize gaps according to impact, likelihood, mission needs, and available resources.
5. Build security into design and development, protect components and release processes, and prepare to respond to residual vulnerabilities.
6. Operate the capability with monitoring, review, incident handling, reassessment, and documented decisions about exceptions or changes.

This workflow should be iterative rather than a one-time approval gate. AI systems, their dependencies, their data, and the threat environment can change. The organization should revisit assumptions when the model, training data, prompts or interfaces, software components, deployment context, or intended use changes. Where a change creates a new risk or invalidates an earlier assessment, the current and target profiles should be updated and the action plan reprioritized.13

Architecture and lifecycle controls

The architecture should make trust boundaries and control responsibilities visible. At minimum, teams should distinguish the data and model lifecycle from the application and infrastructure lifecycle, while connecting them through identity, access, logging, change management, vulnerability handling, and incident response. The cited evidence does not prescribe a single AI architecture; instead, it supports applying ordinary software and information-system security controls together with AI-specific risk management.135

NIST SP 800-218 SSDF Version 1.1 organizes secure development around four practices: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. For AI systems, these practices provide a useful lifecycle baseline. Preparation establishes organizational capability; protection addresses tampering and unauthorized access; secure production addresses vulnerabilities before release; and response addresses residual vulnerabilities and recurrence.4

Secure-by-design work should identify and evaluate software security requirements, determine likely operational security risks, and use design or architecture choices to mitigate them. The SSDF evidence identifies risk modeling, including threat modeling and attack modeling, as examples of ways to address security requirements during design. It also states that addressing requirements and risks during design can improve software security and development efficiency.4

Release and dependency integrity deserve explicit attention. SSDF Version 1.1 recommends making software integrity-verification information available to acquirers, including through cryptographic hashes or code signing, and periodically reviewing code-signing processes such as certificate renewal, rotation, revocation, and protection. It also calls for provenance data to be maintained and for recipients to have a way to verify provenance-data integrity. These measures are relevant wherever AI capability depends on software, models, packages, data-processing components, or other artifacts moving through a delivery pipeline.4

Controls should be selected with both functionality and assurance in mind. NIST SP 800-53 Rev. 5 describes flexible and customizable security and privacy controls implemented as part of an organization-wide risk-management process. It addresses requirements from mission and business needs, laws, directives, regulations, policies, standards, and guidelines, and distinguishes the strength of a control’s function from the confidence that the capability is secure or private. Crosswalks can help compare frameworks, but NIST cautions that mappings are not always one-to-one and should not be treated as proof of equivalency.5

Governance, accountability, and useful measures

Governance should make decisions inspectable. For each material AI capability, record its purpose, scope, assumptions, owner, data and software dependencies, applicable requirements, security objectives, accepted risks, exceptions, approval status, and review conditions. In development workflows, retain evidence of security-check approvals, rejections, and exception requests. This creates an auditable connection between intended outcomes, engineering decisions, and residual risk.34

Measurement should be defined before deployment where possible. SSDF Version 1.1 recommends criteria for software security checks and gives examples including key performance indicators, key risk indicators, vulnerability-severity scores, and other measures for software security. For an AI capability, teams can organize measures around the security outcomes they have selected, then specify how evidence will be collected, who reviews it, and what threshold or trend triggers corrective action. The evidence supports using such measures; it does not establish universal thresholds for every AI system.4

Human accountability remains important when AI outputs influence security decisions. The cited evidence does not define a universal human-in-the-loop requirement, nor does it prescribe particular operational thresholds. Organizations should therefore document which decisions AI may recommend, which actions it may perform, what review or escalation is required, and how operators can challenge, suspend, or correct an outcome according to the system’s risk and mission. Those arrangements should be tested as part of evaluation and incident response.134

Risks and limitations

AI systems inherit many risks from conventional software and introduce additional concerns. NIST identifies overlapping confidentiality, integrity, and availability concerns affecting the system, training data, and output data, along with the underlying software and hardware. The research material further states that existing frameworks and guidance cannot comprehensively address security concerns related to evasion, model extraction, membership inference, availability, or other machine-learning attacks, and do not account fully for the complex attack surface or security abuses enabled by AI systems.1

• Treating a model assessment as a complete system-security assessment, while overlooking applications, infrastructure, dependencies, data, or users.
• Assuming that a framework crosswalk proves equivalent coverage instead of analyzing the scope and intended use of each publication.
• Releasing software, models, or components without a reliable way to verify integrity or provenance.
• Defining no measurable security criteria, making it difficult to determine whether controls work or whether risk is increasing.
• Failing to reassess when the AI system, data, dependencies, deployment context, or use case changes.
• Treating AI risk as separate from enterprise cybersecurity, privacy, operational, reputational, and financial risk.

The limitations are material for decision-makers. NIST AI RMF 1.0 is intended for voluntary use, and NIST states that security and resilience challenges and potential solutions are changing rapidly. The framework can improve the incorporation of trustworthiness considerations, but it is not evidence that a system is secure, compliant, or risk-free. Organizations must apply judgment, select controls appropriate to context, and maintain an improvement process as knowledge and threats evolve.21

Authoritative guidance and practical next steps

The source set contains complementary NIST publications rather than a single mandatory AI-cybersecurity standard. NIST AI RMF 1.0 was released on January 26, 2023 and is intended to improve the ability to incorporate trustworthiness into the design, development, use, and evaluation of AI products, services, and systems. NIST also released the Generative AI Profile, NIST AI 600-1, on July 26, 2024; the cited evidence says it can help organizations identify unique generative-AI risks and propose actions aligned with organizational goals and priorities.2

NIST CSF 2.0, published February 26, 2024 as NIST CSWP 29, provides a taxonomy of high-level cybersecurity outcomes that organizations can use to understand, assess, prioritize, and communicate cybersecurity efforts. It does not prescribe how outcomes must be achieved. NIST SP 800-53 Rev. 5 provides a flexible control catalog for security and privacy, while NIST SP 800-218 SSDF Version 1.1 provides secure-development practices, tasks, and implementation examples. Used together, these resources can connect enterprise outcomes, control selection, and engineering execution without assuming that one publication replaces the others.354

1. Inventory AI use cases and classify them by mission impact, data sensitivity, operational dependency, and exposure.
2. Assign accountable owners and document current assumptions, requirements, dependencies, and risk decisions.
3. Create a current and target cybersecurity profile using outcomes relevant to the AI capability.
4. Apply secure-by-design analysis and SSDF practices to applications, models, data-processing components, dependencies, and release artifacts.
5. Implement integrity and provenance verification appropriate to the delivery pipeline, and protect signing or verification processes.
6. Define security KPIs, KRIs, severity measures, approval records, exception handling, and escalation paths.
7. Evaluate the system before release and after material change; use findings to update the profile and action plan.
8. Review emerging AI-specific attack research and update safeguards, because current guidance does not comprehensively cover every AI security concern.

Conclusion

AI in cybersecurity is both a defensive opportunity and a security responsibility. Enterprise teams should manage it as a lifecycle capability: define the mission and accountability, integrate AI risk with enterprise risk, profile current and target outcomes, build security into design and development, protect software and provenance, measure control performance, and reassess as systems and threats change. NIST AI RMF 1.0, CSF 2.0, SP 800-53 Rev. 5, and SSDF Version 1.1 offer complementary starting points, but none removes the need for context-specific judgment or ongoing research-informed improvement.1342