AI tools often enter through shadow adoption, embedded features, or external APIs, which means they can be active before they are formally inventoried or contracted. That creates blind spots in registers, concentration analysis, and monitoring, so the institution may be compliant on paper but incomplete in practice.
Why This Matters for Security Teams
DORA assumes firms can identify, classify, and monitor the technology they depend on, but AI tools often bypass that discipline by arriving through shadow adoption, embedded product features, or external APIs. That makes the governance gap operational, not theoretical: the tool may be active before procurement, inventory, risk assessment, or exit planning ever happens. For financial institutions, that is a resilience issue as much as a compliance issue, especially when third-party dependencies are opaque.
This is why DORA-oriented control design has to extend beyond applications and vendors to the identities, secrets, and permissions behind AI activity. The challenge overlaps with broader NHI governance, including lifecycle control and audit readiness described in Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the failure modes catalogued in Top 10 NHI Issues. Current guidance also aligns with the EU Digital Operational Resilience Act (DORA), which expects firms to understand operational dependencies, not merely hold contracts. In practice, many security teams encounter AI exposure only after access sprawl or vendor review has already missed the real control points.
How It Works in Practice
AI creates a DORA gap because the risk surface is split across business users, SaaS settings, development pipelines, and machine identities. A chatbot embedded in a collaboration tool may use a vendor-controlled model, a service account, and outbound APIs, yet only one of those elements appears in the asset register. If the institution tracks the application but not the secrets, tokens, and delegated permissions that make it work, concentration risk and operational dependency analysis remain incomplete.
Practically, firms need to map AI use to the identity layer, then treat each workload as a governed dependency. That means inventorying agents, service accounts, API keys, and tokens as NHIs, reviewing who can issue them, and ensuring short-lived access where possible. The lifecycle approach in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is especially relevant when AI tools are added without formal change control. For control mapping, NIST Cybersecurity Framework 2.0 helps structure identification, protection, detection, and response, while NIST SP 800-63 Digital Identity Guidelines reinforces the need to bind actions to a verified identity rather than an assumed application trust.
- Track every AI entry point, including embedded copilots, plugins, and API-mediated workflows.
- Register the non-human identities behind those tools, not just the vendor name or UI label.
- Classify the data exposed to model prompts, retrieval layers, and downstream automation.
- Review credential ownership, rotation, and revocation so dormant access does not persist.
These controls tend to break down when AI is deployed through unmanaged SaaS features and users can enable them without security or procurement review.
Common Variations and Edge Cases
Tighter governance often increases operational friction, requiring organisations to balance faster AI adoption against slower intake, approval, and review cycles. That tradeoff is real, and current guidance suggests there is no universal standard for how aggressively to block shadow AI versus wrap it in compensating controls.
One edge case is internally developed AI that looks low risk because the model is hosted inside the perimeter. Even then, the control issue may sit in the delegated identities, retrieval connectors, and service tokens that let the system act on behalf of a user or process. Another case is vendor-managed AI where the institution cannot see the underlying model operations. In that situation, the institution still owns the DORA obligation to understand material dependency and residual risk, even if telemetry is limited.
For financial institutions, the most common failure is assuming that contractual due diligence equals operational control. It does not. The better test is whether the institution can explain, at any point, which AI systems are live, which NHIs they use, what data they can reach, and how quickly those identities can be revoked if the service misbehaves or the vendor fails. That is also where issues highlighted in the DeepSeek breach become instructive: hidden exposure is often discovered only after the environment has already been expanded beyond governance. Best practice is evolving, but the direction is clear: DORA evidence must follow the actual AI workload, not the paperwork trail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST AI RMF set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Directly addresses ICT dependency mapping and operational resilience oversight. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | AI tools rely on credentials and secrets that often go unmanaged. |
| NIST AI RMF | Supports governance for AI systems whose behaviour and risk can change at runtime. |
Inventory AI dependencies and prove monitoring, testing, and exit readiness for each material service.
