| Audience: | CIOs 🞄 CISOs 🞄 CTOs |
| Industry Sectors: | Financial Services 🞄 Healthcare Systems 🞄 Government/Public Sector |
| Decision Horizon: | Immediate; before material AI capability expansion |
Executive Summary
Existing cybersecurity controls remain a legitimate foundation for AI security. But a control that protects an established application may not adequately protect new retrieval paths, delegated permissions, or executable actions introduced through AI.
CIOs should condition consequential AI capability expansion on demonstrated control coverage, not the existence of previously approved security controls.
The distinction is between control operation (whether a mechanism performs as designed) and control coverage (whether it protects the exposure now being introduced). An operational control can leave a newly exposed AI security boundary unprotected.
Retain existing controls where coverage is demonstrated, modify or augment them where necessary, and restrict new capabilities where adequate protection cannot be established. Neither reuse nor specialized AI-security tooling warrants automatic approval.
Our Analysis
AI does not invalidate established cybersecurity principles. It can, however, invalidate assumptions about where those principles are enforced.
Conventional security mechanisms may continue functioning correctly while newly introduced AI capabilities operate beyond the scope those mechanisms were originally assessed to protect.
The Narrative vs The Reality
Enterprises face a practical choice between extending established cybersecurity capabilities and adding controls designed for AI-specific exposures. Pentera's 2026 survey of 300 US security executives found that 75% reported extending controls developed for other attack surfaces. This establishes reported practice, not control effectiveness.1
NIST's preliminary Cyber AI Profile builds on Cybersecurity Framework 2.0 outcomes, while OWASP AISVS 1.0 complements established application-security standards with AI-specific verification requirements.2,3
NIST SP 800-53A Rev. 5 already provides adaptable procedures for assessing security-control effectiveness. The requirement is not a new AI-security assessment regime. It is evidence that existing assessments cover the security boundaries AI introduces.6
Five realities complicate the choice between conventional and AI-specific controls:
- Control objectives remain relevant. Authentication, authorization, data protection, and monitoring still apply. Their implementations must cover the AI system's actual behavior.
- A functioning control can leave an exposure uncovered. An AI service can authenticate successfully while retrieving information or invoking tools beyond the requesting user's authorization. OWASP AISVS requires end-user authorization to remain enforceable through retrieval pipelines.3
- Correct authorization does not establish legitimate intent. Greshake and colleagues demonstrated that malicious instructions embedded in retrieved content can redirect LLM-integrated applications and influence API calls. An agent can therefore act within its technical permissions but contrary to the user's intended task.7
- Coverage can change without replacing security infrastructure. Connecting a repository, enabling transaction execution, or materially changing how an agent selects actions can introduce exposure outside the previous assessment.
- Specialized defenses also require verification. Nasr and colleagues bypassed 12 evaluated language-model defenses using adaptive attacks, achieving success rates above 90% against most in their experimental settings. Specialization alone did not establish robustness.4
The Signal in the Noise
Neither inherited controls nor AI-specific products establish adequate protection merely by being present.
What Changes the Decision
Consider a hypothetical internal AI assistant originally approved to answer questions from a public knowledge base.
The organization subsequently connects it to confidential customer records and a transaction-processing tool. Authentication remains operational, and the tool's service account has valid permissions. However, those permissions may exceed the authority of the employee making the request.
Authentication is operating correctly, but authorization coverage is incomplete if the assistant can retrieve or act beyond that employee's permissions. The failure is not necessarily in the existing mechanism; it is in assuming the mechanism covers the new execution path.
If the organization's existing authorization service independently enforces employee permissions at retrieval and transaction boundaries, and verification confirms that enforcement, retain it. AI mediation alone does not justify another security product.
Authorization does not, however, establish that every permitted action is intended. An attacker-controlled document might induce a transaction the employee could authorize but never requested. Consequential workflows therefore require independently enforced limits on permitted operations and parameters. These limits constrain what the agent can do; they do not establish that every action remaining within those limits reflects legitimate user intent.3,7
Where existing mechanisms cannot enforce the required boundaries, modify or augment them. Until coverage is established, restrict the additional capability.
Why This Matters Now
NIST's February 2026 agent identity concept paper identifies delegation, authorization, auditing, and multi-application access as challenges requiring further technical work.5 These concerns become consequential when AI applications acquire access to sensitive information or executable business functions.
The relevant exposure varies by workflow. In financial services, it may involve transaction authority; in healthcare, restricted clinical information; and in government, changes to authoritative administrative records.
What to Watch for Next
Expanded retrieval permissions, executable integrations, and material changes in model or tool behavior can invalidate prior coverage. Individually minor changes can also accumulate into exposure that the original assessment did not cover.
Recommended Actions
Do This
- Reassess when AI materially changes an approved security boundary. Before production activation, the AI service owner must identify expanded sensitive-data access, delegated permissions, executable actions, or behavioral changes that could invalidate prior coverage. The CISO's assurance function independently determines whether targeted verification is required. Model, system-prompt, and tool-description changes trigger reassessment when they materially affect exposure, even if formal permissions remain unchanged.
- Apply a coverage-based control decision. Record the security outcome required at each newly exposed boundary:
- Retain existing controls when coverage is demonstrated.
- Modify inherited controls when their enforcement can be extended.
- Augment when complementary enforcement is necessary.
- Restrict the additional capability when coverage remains inadequate or unverified.
Restriction should preserve usable, protected functionality. For example, limit the assistant to approved read-only data, disable agent-executed transactions, or require an authorized employee to perform transactions through the existing controlled workflow. Restore additional capabilities only when their required protection is demonstrated.
- Require enforcement evidence supported by targeted testing. For consequential AI-mediated access or execution, verify that permissions and action constraints are enforced through application logic or an independent policy mechanism, not model instructions. Establish that the policy covers the relevant actions, parameters, and execution paths. Test permitted, prohibited, and attacker-induced behavior. Independent enforcement establishes specified boundaries; behavioral testing provides bounded evidence about how the system behaves under attack.3,4
Avoid This
- Do not select controls by product category alone. Establish the security outcome and uncovered exposure first. Retain existing mechanisms where sufficient; introduce specialized capabilities when they provide necessary protection.
- Do not transfer security approval beyond its assessed scope. Previously approved controls cannot establish coverage of materially new authority or execution paths. Equally, avoid full reassessment of changes that do not materially alter exposure, considering their cumulative effect.
Bottom Line
A control can work exactly as designed and still fail to cover what AI has been permitted to do. Retain existing controls when coverage is demonstrated. Change the protection, not necessarily the product, when AI crosses an unverified security boundary.
Evidence and Sources
- Pentera. 2026. AI Is Spreading Faster Than Companies Can Secure It, CISO Survey Finds. February 18. Vendor-sponsored survey of 300 US security executives; self-reported practice.
- National Institute of Standards and Technology. 2025. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). NIST IR 8596, Initial Preliminary Draft, December 16.
- OWASP Foundation. 2026. Artificial Intelligence Security Verification Standard (AISVS), Version 1.0. June. Particularly v1.0-C5.2.2, C9.3.5, and C9.5.1–C9.5.3.
- Nasr, Milad, et al. 2026. The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections. 35th USENIX Security Symposium, August. Evaluates jailbreak and prompt-injection defenses, not deterministic authorization controls generally.
- National Institute of Standards and Technology. 2026. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. NCCoE Concept Paper, February 5.
- National Institute of Standards and Technology. 2022. Assessing Security and Privacy Controls in Information Systems and Organizations. NIST SP 800-53A, Revision 5, January 25.
- Greshake, Kai, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. 2023. Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. February; revised May. Experimental demonstration of indirect prompt injection, not enterprise incident prevalence.