AI systems increase risk because they expand the number of assets, data paths, and operational decisions that must be secured at once. When training data, workloads, and supporting services span multiple clouds and applications, attackers gain more opportunities to poison data, steal models, or abuse exposed systems. The result is greater complexity, slower defense updates, and more ways to compromise confidentiality, integrity, and availability.
How AI Raises Risk Across Shared Infrastructure
AI increases security risk because it adds a new layer of compute, data, and orchestration on top of existing cloud and application environments. The risk is not just that AI is “another workload”; it is that AI workflows often depend on training data, model artifacts, APIs, plugins, pipelines, and third-party services that all need to be secured together. That widens the blast radius when one control fails.
Modern AI deployments also tend to cross platform boundaries. A single system may pull data from object storage, call internal applications, invoke external services, and publish outputs into downstream business processes. Each integration point becomes a place where attackers can poison inputs, expose data, or exploit over-privileged access. In practice, complexity itself becomes part of the attack surface.
The operational impact is compounded by speed. Model updates, retraining cycles, and rapid application release pipelines can move faster than review processes, so security teams often inherit more change with less time to validate it. That creates a familiar pattern: more assets to inventory, more trust relationships to verify, and more places where misconfiguration survives long enough to matter.
NHIMG’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges. Those numbers matter here because AI systems usually depend on the same credential and privilege layer as the rest of the infrastructure, so AI risk often becomes infrastructure risk by another name.
Why the Attack Surface Expands So Quickly
AI systems are attractive to attackers because they concentrate valuable data and automate decisions. Training sets, prompts, retrieval sources, model weights, and operational logs can all reveal sensitive information or influence system behaviour. When those assets are spread across multiple clouds and teams, defenders must secure not only the model itself but also every upstream and downstream dependency that can affect it.
That creates three recurring failure modes. First, data exposure, where sensitive inputs or outputs leak through logs, prompts, caches, or integrations. Second, integrity loss, where poisoned data or manipulated context changes what the system learns or returns. Third, availability and abuse issues, where exposed endpoints, overloaded services, or uncontrolled automation disrupt normal operations.
The challenge is that AI systems often look safe at the model layer while being weak at the integration layer. A well-tuned model does not compensate for exposed secrets, weak service permissions, or unreviewed connectors. For practitioners, the key question is not whether the model is accurate in isolation, but whether the surrounding data paths and service dependencies can be trusted end to end.
For threat context, DeepSeek breach shows how exposed log lines and sensitive secret keys can turn an AI-related environment into a broader compromise path. The same pattern appears in Google Firebase misconfiguration breach, where misconfiguration exposed secrets at scale across developer infrastructure.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | AI systems rely on machine credentials and exposed secrets across pipelines and services. |
| NHI-04 — Least Privilege and Access Governance | AI orchestration often overextends service permissions across clouds and applications. | |
| NHI-07 — Visibility and Detection | AI risk grows when teams cannot see who or what is accessing models, data, and tools. | |
| Recommendation — Inventory and rotate AI-related secrets, then remove hardcoded credentials from code and build systems. Restrict AI service accounts to the minimum permissions needed for each data path and action. Log and monitor AI tool use, credential usage, and unusual access patterns across the workflow. | ||
| NIST CSF 2.0 | ID.AM — Asset Management | AI expands the number of assets, data paths, and dependencies that must be inventoried. |
| PR.AA — Identity Management, Authentication and Access Control | AI systems depend on bounded access to data, tools, and downstream actions. | |
| GV.RM — Risk Management Strategy | AI increases complexity and change speed, which changes organisational risk posture. | |
| Recommendation — Maintain an accurate inventory of AI models, datasets, connectors, and supporting services. Apply strong access control to AI data sources, model endpoints, and automation pathways. Set risk thresholds and review gates for AI changes that alter data access or service trust. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Where AI workflows rely on authenticated users or operators, assurance level shapes trust in actions. |
| Recommendation — Require the appropriate assurance level before allowing privileged AI administration or approval steps. | ||
| CIS Controls v8 | CIS 6 — Access Control Management | AI environments become riskier when permissions are broader than the task requires. |
| CIS 8 — Audit Log Management | AI abuse and misconfiguration are easier to detect when interactions are logged consistently. | |
| Recommendation — Review and revoke unnecessary access to AI services, datasets, and orchestration systems. Centralise logs for model calls, connector use, and administrative changes to AI systems. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | AI pipelines often expose secrets through code, logs, configs, and CI/CD paths. |
| Recommendation — Hunt for exposed AI credentials in repositories, logs, and configuration stores. | ||
Practitioner Guidance
What to prioritise: Start with the trust boundaries around data ingestion, model access, and downstream action. If an AI system can read sensitive data and then trigger other systems, treat that path as a high-value control point and verify the permissions behind it before expanding functionality.
What to verify: Confirm where secrets live, which services can reach the model, and whether any AI-related account can act outside its intended environment. If the answer is unclear, assume the blast radius is larger than the current inventory suggests and validate the actual credential path, not just the documented one.
What practitioners underestimate: The hardest problem is usually not the model, it is the orchestration around it. Security risk rises fastest when AI is allowed to consume broad data sources, call tools, and publish outputs faster than governance can keep pace with those changes.
Practitioner takeaway: The safest AI deployments are not the most automated ones, they are the ones where data access, service reach, and output authority are tightly bounded and observable.
Related resources from NHI Mgmt Group
- Why do AI-enabled marketing systems increase privacy and security risk at the same time?
- Why do AI systems increase identity risk even when they improve security operations?
- Why do frontier AI systems increase recovery risk for security teams?
- Why do AI and IoT systems increase healthcare security risk?
