AI systems have changed how enterprise risk appears, moves, and gets documented. Cybersecurity assessment services now need to cover the attack surfaces created by models, agents, retrieval systems, and connected tools.
What this article covers:
- The EU AI Act and DORA are forcing cybersecurity assessments to reflect AI systems already operating in production.
- OWASP’s 2025 LLM Top 10 places prompt injection as the leading AI security risk for large language model deployments.
- RAG systems expand the assessment scope because the retrieval corpus becomes part of the security boundary.
- Agentic AI requires permission reviews that examine combined tool access, not only individual system permissions.
- AI systems deploye
- d between assessment cycles need current-state gap analyses before outdated documentation becomes regulatory exposure.
The EU AI Act’s high-risk AI compliance deadline is August 2, 2026, when obligations for high-risk AI systems in Annex III enter into full application. DORA—the Digital Operational Resilience Act—has been fully applicable since January 17, 2025, for financial entities operating in the EU. OWASP’s LLM Top 10, updated in 2025, identifies prompt injection as the leading vulnerability (LLM01) in large language model deployments.
These three facts, taken together, describe a compliance problem that most enterprises have not yet named. Organizations that completed cybersecurity assessments before AI became a standard component of their production stack, or that are running assessments today using frameworks built for pre-AI environments, are generating compliance documentation for attack surfaces that no longer match what they are actually operating.
The assessment exists, and the controls are documented. But the risk profile it describes is from a different architecture altogether.
The New Attack Surface is Hidden in Ordinary Inputs
Until AI systems became production infrastructure, enterprise cybersecurity assessments operated on a relatively stable model of the environment being assessed. Applications had defined inputs, data flows were bounded by system architecture, and privilege escalation required either a compromised credential or a specific technical exploit.
But AI systems, particularly agentic AI systems that can retrieve data, take actions, and chain reasoning steps across tools and APIs, change the threat model in ways that standard assessment frameworks do not cover.
Prompt injection
Prompt injection is the most documented of these. An attacker who can influence text that an AI system will process—through a malicious document in a retrieval corpus, a poisoned email in an inbox agent’s context, or injected instructions in a form field—can potentially redirect the model’s behavior without touching the application layer. No credential is required. No exploit code is necessary. The input is language, and the AI system processes it.
OWASP’s LLM Top 10, updated in 2025, ranks prompt injection as the number one vulnerability (LLM01) in large language model deployments. This is not a statement about software defects but one about architectural exposure. Most organizations that deployed AI systems built their control frameworks around the inputs those systems were designed to process. They did not design for adversarial inputs because adversarial inputs in a language model look like ordinary text.
Retrieval-augmented generation (RAG) poisoning
RAG poisoning is a related vector that has emerged as RAG architectures moved from experimental to standard in enterprise AI deployments. In a RAG system, an AI model retrieves documents from a corpus (internal knowledge bases, contract repositories, compliance documentation, or customer records) and uses them to generate responses. If that corpus contains manipulated content, the model incorporates it without flagging it. The security boundary is the corpus. Most cybersecurity assessments were not designed to assess corpus integrity as a control domain.
Agentic privilege escalation
Agentic systems that can invoke tools, call APIs, and take multi-step actions across systems require permission structures that most enterprise environments have not designed. An agent given access to a calendar system, an email client, and a CRM—individually reasonable permissions—can, under adversarial conditions, combine those capabilities in ways that no single-system access policy anticipates. The assessment question is not whether the agent has appropriate permissions to the calendar but whether the combination of permissions across all tools the agent can invoke creates exposure that would not exist if a human held the same access.
Older Assessment Scopes are Becoming a Compliance Liability
The regulatory calendar has compressed the timeline for organizations that were planning to address AI security incrementally.
DORA’s requirements for financial entities in the EU include digital operational resilience testing, ICT risk management, and incident reporting obligations that apply to AI-powered systems running in production. Organizations that completed their DORA gap analysis before deploying AI systems or that completed it using a scope definition that excluded AI components are carrying compliance documentation that does not reflect their current operational environment.
The EU AI Act’s August 2, 2026 deadline applies to high-risk AI systems as defined in Annex III of the Act: AI used in critical infrastructure, in consequential decisions about individuals in employment, education, or essential services, in law enforcement and border management, and in certain financial services contexts. Organizations deploying AI in any of these domains are required to have conformity assessments, technical documentation, and ongoing monitoring in place. The risk assessment that supports those requirements must reflect the actual AI system, including its attack surface, not a generalized description of AI deployment.
In US financial services, the SEC’s 2026 examination priorities explicitly identify AI-driven threats and third-party AI model risk as areas of focus. The 20 US states that have enacted consumer privacy statutes with automated decision-making provisions create a separate but overlapping set of documentation requirements for organizations using AI in customer-facing decisions.
None of these regulations require a specific assessment methodology. However, all of them require that the risk documentation accurately describes the environment being assessed and the controls that govern it. That requirement is the source of the compliance gap: assessments designed for environments without AI in the production stack cannot accurately document environments where AI is now part of the production stack.
A Current Assessment Has to Follow the AI System’s Actual Paths
The components that distinguish an enterprise cybersecurity assessment scoped for AI-augmented environments from a standard infrastructure assessment are not entirely new. In fact, several involve applying existing security disciplines, such as threat modeling, access control review, and data integrity verification, to system types those disciplines were not originally designed to assess.
Prompt injection and adversarial input testing
A current-state assessment tests whether AI systems in production can be redirected by adversarial inputs presented through their intended input channels, and not just through direct API access. This requires understanding how the system processes documents, emails, form inputs, or other external text, and whether inputs from those channels reach the model in a form that can affect its behavior.
Retrieval corpus integrity
For systems using RAG architectures, the assessment must include the corpus as a control domain: who can write to it, what validation exists for content entering it, how frequently it is reviewed for anomalous content, and what happens when retrieval returns content that conflicts with other sources. Corpus poisoning does not require access to the AI system itself but to the document store, which often has significantly more permissive controls.
Agent permission architecture
For agentic systems, the assessment must map the combination of tool access each agent holds and evaluate whether that combination creates exposure that individual tool access policies do not anticipate. This requires the organization to have documented what tools each agent can invoke, under what conditions, and what actions those tools can take on the agent’s behalf. Many organizations have not produced this documentation; the assessment process frequently surfaces it for the first time.
Model and prompt versioning controls
Changes to the model, the prompt templates, or the retrieval configuration of an AI system are configuration changes that affect security posture. Standard change control processes that govern application code do not automatically extend to these components. An assessment that does not review model versioning, prompt template history, and retrieval configuration change logs is not assessing the full attack surface.
Audit trail coverage
Regulations that require explainability and documentation of AI-driven decisions require that the organization can produce, after the fact, a record of what information the model retrieved, what reasoning steps it followed, and what output it generated. In practice, many AI systems log outputs but do not log the full reasoning trace. An assessment that identifies this gap before a regulatory examination is considerably less expensive than one that surfaces it during one.
The Assessment Sequencing Problem
Cybersecurity assessments in most enterprises are scheduled events: annual reviews, regulatory examination cycles, or post-incident responses. The AI systems those assessments now need to cover were, in most cases, deployed between assessment cycles.
The practical result is that organizations are frequently operating AI systems in production for 12 to 24 months before those systems appear in a formal cybersecurity assessment scope. During that window, the system has been integrated with production data, connected to downstream workflows, and used to inform decisions without having its security posture formally documented.
This is not negligence in most cases. It is a sequencing artifact: assessment cycles were designed for a pace of change that predates the AI deployment rate of 2024 and 2025. The problem is that the remediation cost of a security gap identified in a post-incident review is substantially higher than the cost of identifying the same gap during a proactive assessment.
According to IBM’s 2025 Cost of a Data Breach Report, breaches involving shadow AI cost an average of $4.63 million, adding $670,000 to breach costs for organizations with high shadow AI usage. Meanwhile, the average time-to-exploit for vulnerabilities collapsed from 32 days to just 5 days, meaning attackers are weaponizing flaws in weeks rather than months.
This is not about negligent organizations. It’s about enterprises deploying AI without assessment frameworks designed for the attack surfaces they were creating.
Fulcrum Digital Starts With the Production AI Footprint
Fulcrum Digital’s cybersecurity assessment practice was developed against the same production environments where we build AI systems. Which means the assessment frameworks we apply to AI-augmented environments reflect actual deployment patterns, not hypothetical threat models.
For organizations subject to DORA, the EU AI Act, or US financial services regulatory requirements, Fulcrum’s assessment approach begins with scoping that explicitly identifies AI systems in production, their data access patterns, their tool permissions, and the regulatory frameworks that govern them. The assessment covers prompt injection exposure, corpus integrity controls, agent permission architecture, model and prompt change management, and audit trail completeness, in addition to the infrastructure, identity, and network controls that standard assessments cover.
For organizations that have completed assessments recently but deployed AI systems since, Fulcrum’s gap analysis process identifies which components of the current security posture have been affected by AI deployment and what documentation needs to be updated to accurately reflect current controls.
The goal is compliance documentation that describes the environment the organization is actually operating and not the environment the organization was operating when its last assessment was designed.
If your AI systems have moved faster than your cybersecurity assessment scope, Fulcrum Digital’s cybersecurity team can help you identify the gaps before they surface through an audit, incident, or regulatory review.
Related reading: Where Compliance Meets Capability looks at how agentic AI can support DORA-aligned oversight through continuous monitoring, escalation workflows, and audit-ready evidence.
Frequently Asked Questions
What is a cybersecurity assessment for enterprise AI environments?
A cybersecurity assessment for enterprise AI environments evaluates whether AI systems introduce risks that standard infrastructure assessments may miss. It looks at how models receive inputs, retrieve information, access tools, change over time, and produce records that may later need to be audited. For AI systems already in production, the assessment should reflect the environment as it operates today.
Why do standard cybersecurity assessments miss AI-specific risks?
Standard cybersecurity assessments were built around applications with predictable inputs and clearly defined access paths. AI systems behave differently because ordinary language, retrieved documents, or connected tools can influence system behavior. A malicious instruction hidden inside a document or message may never touch the application layer, yet still affect what the model does.
What regulatory requirements apply to AI cybersecurity assessments in 2026?
Several frameworks now make AI security documentation harder to treat as optional. The EU AI Act’s high-risk AI obligations begin applying on August 2, 2026, while DORA has applied to EU financial entities since January 2025. In the US, financial regulators are also examining AI-driven threats and third-party model risk. Each organization should confirm its exact obligations with legal and compliance counsel.
What is RAG poisoning and why does it matter for cybersecurity assessments?
RAG poisoning happens when manipulated or unreliable content enters the document collection an AI system uses to generate answers. The model may then treat that content as valid source material. This matters because the security boundary is no longer only the application or model; it also includes the knowledge base, document store, or internal repository the system relies on.
How does Fulcrum Digital conduct cybersecurity assessments for AI environments?
Fulcrum Digital assesses AI environments by looking beyond standard infrastructure controls. The process examines how AI systems handle adversarial inputs, how retrieval sources are governed, what tool access agents have, how model and prompt changes are managed, and whether audit trails are complete enough for regulatory review. The goal is documentation that matches the system currently in production.
What is the right sequencing for AI cybersecurity assessments?
AI cybersecurity assessments should ideally begin before deployment, while architecture, data access, and agent permissions are still being designed. For systems already running in production, a current-state gap analysis is the practical starting point. After that, formal reassessments should follow material changes such as new models, new tools, new data sources, or expanded regulatory exposure.
