AI security risks in 2025 expose identity and data control gaps

At a glance

What this is: Obsidian Security says enterprise AI risk in 2025 is being driven by adversarial inputs, data poisoning, prompt injection, and weak AI identity controls that stretch from training pipelines to runtime access.

Why it matters: This matters because AI systems are now part of operational workflows, so IAM, NHI, and AI security teams need controls that govern model behaviour, agent authentication, and data integrity together.

Context

AI security is no longer just a model-quality problem. Once AI systems handle business workflows, the security boundary expands to include training data, runtime prompts, agent credentials, APIs, and the decisions these systems make on behalf of the enterprise. That makes classic application security necessary but insufficient, because the control gap is now in how identity, data, and behaviour are governed across the AI lifecycle.

The article focuses on a familiar but still poorly governed pattern: AI systems often inherit access and trust assumptions faster than security teams can verify them. In identity terms, that means agents, APIs, and connected services can become high-impact access paths without the lifecycle controls that normally surround human or service identities.

Key questions

Q: What breaks when AI agents are given broad enterprise access without tight governance?

A: Broad access turns AI agents into high-speed execution paths that can move data, spend money, modify records, or delete assets before operators can intervene. The failure is not only misuse by an attacker. The system itself can exceed intended scope during normal task completion, so the real control problem is bounding authority before runtime action begins.

Q: Why does AI make identity security a resilience issue?

A: AI raises the operational tempo around access decisions, which means identity failures can affect containment, recovery, and continuity, not just initial compromise. If revocation, ownership, or restoration is slow, the organisation may recover systems while leaving the identity layer inconsistent and exploitable.

Q: What are the signs that an AI environment is becoming insecure?

A: Warning signs include publicly reachable model code, exposed notebooks, secrets stored in repositories, vulnerable package dependencies, and data sets that are open to modification or deletion. Another clear signal is overly permissive access around model interfaces and training data. When those conditions exist together, the environment is moving from managed AI to uncontrolled exposure.

Q: How should organisations balance AI innovation with control boundaries?

A: Organisations should permit AI adoption only where access, provenance, and monitoring are explicit design requirements. The right balance is not slowing AI down universally. It is defining which workflows can tolerate autonomous behaviour, which must remain human-approved, and which require strict identity controls from the start.

Technical breakdown

Why adversarial machine learning bypasses static security checks

Adversarial machine learning uses carefully crafted inputs to change a model's output without triggering obvious human review. The attacker is not breaking the infrastructure first. Instead, they are exploiting the model's sensitivity to small perturbations in the input space, which can cause misclassification, unsafe recommendations, or incorrect automated decisions. This is why conventional perimeter controls miss the threat. The model may be functioning exactly as designed from a software perspective while still producing compromised results. In enterprise settings, that creates a gap between system availability and decision integrity.

Practical implication: security teams need model-aware monitoring and adversarial testing, not just network or endpoint controls.

How data poisoning creates durable model compromise

Data poisoning targets the training or fine-tuning stage by inserting malicious or corrupted samples into the datasets a model learns from. Because the bad data becomes part of the model's learned behaviour, the compromise can persist long after the original source is removed. This is especially dangerous in continuous learning pipelines, federated training, and environments that ingest third-party data without strong provenance checks. A poisoned model can appear healthy in standard testing while still encoding attacker influence in its outputs. The control problem is therefore integrity of inputs, not only accuracy of outputs.

Practical implication: treat training-data provenance and model version integrity as security controls, not just MLOps hygiene.

Why AI agent authentication becomes an identity problem

AI agents and automated systems often act with broader permissions than the tasks they execute require. That makes their authentication and authorisation model more like NHI governance than traditional application access. If an agent can call APIs, access SaaS systems, or forward tokens between services, then a compromised prompt or integration becomes an identity event, not just an AI event. The article correctly points to zero-trust principles here because the real issue is trust expansion across delegated actions, tokens, and connected systems. Once an agent is allowed to move laterally through enterprise data, the blast radius is defined by access scope.

Practical implication: bind every AI agent to least-privilege identity, short-lived credentials, and explicit API boundaries.

Threat narrative

Attacker objective: The attacker aims to influence AI-driven decisions, steal sensitive data, or turn trusted AI workflows into an access path into enterprise systems.

1. Entry occurs through adversarial inputs, prompt injection, or poisoned training data that changes model behaviour without immediately visible compromise.
2. Credential and access abuse follows when AI agents or automated systems operate with excessive privileges or weak authentication across APIs and SaaS integrations.
3. Impact occurs when manipulated outputs, poisoned decisions, or stolen data influence business processes such as fraud detection, recommendations, or operational workflows.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security has become an identity governance problem, not just a model safety problem. Once agents, APIs, and connected services can act inside enterprise workflows, their credentials and permissions become the real security boundary. That shifts the centre of gravity from static model review to lifecycle control over who or what can act, for how long, and with which data. Practitioners should treat AI identities as governed assets, not implicit extensions of the application stack.

Data poisoning creates governance debt because the compromise is baked into the model's behaviour. This is qualitatively different from a transient runtime exploit. If the training pipeline accepts untrusted input, the organisation may inherit a compromised decision system that passes ordinary security tests while still producing attacker-shaped outcomes. Practitioners should align AI assurance with provenance, version integrity, and controlled data sourcing.

Identity-first AI security is the only defensible response when autonomous systems inherit enterprise trust. The article's own emphasis on zero trust is directionally correct because trust expansion, not just technical vulnerability, is what gives AI incidents their blast radius. For security teams, the key question is whether AI actions are bounded by explicit authorisation and observable controls. Practitioners should make access scope the first design constraint.

Obsidian Security's article points to a new control gap we can call AI access sprawl. That is the gap between an AI system's functional purpose and the breadth of access it accumulates across data, APIs, and downstream services. The more broadly agents are connected, the more important entitlement review, token scope, and API governance become. Practitioners should measure AI trust expansion the same way they measure human privilege creep.

Security operations need visibility into AI behaviour, not only AI incidents. The article is right that traditional monitoring misses model drift, prompt abuse, and access misuse because those signals sit above the infrastructure layer. This is where AI Security Posture Management and behavioural baselining matter. Practitioners should treat anomalous model output, unusual token use, and unexpected data access as governable signals, not isolated alerts.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

AI access sprawl: the practical problem is not simply that AI systems exist, but that they accumulate permissions across prompts, APIs, and downstream services faster than governance teams can certify them. That makes access scope the decisive variable in AI risk management, especially where agents can act without a human in the loop.

According to the 2026 Infrastructure Identity Survey, systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, and organisations failing to scope AI access properly were 4.5x more likely to experience a security incident. That is a strong signal that privilege scope, not model novelty, is where controls should be tightened first.

For practitioners

• Inventory every AI model, agent, and connected data pipeline Create a complete register of production and shadow AI assets, then classify each by business criticality, data sensitivity, and external connectivity. Use that inventory to identify where AI has access to customer data, financial workflows, or internal systems that would widen blast radius if compromised.
• Constrain AI access with least privilege and short-lived credentials Assign each agent or model integration only the APIs, datasets, and SaaS actions it truly needs, with token lifetimes and scopes tied to task duration. Review whether any system can forward credentials, call downstream services, or reach regulated data without explicit authorisation.
• Verify training data provenance and model integrity Add provenance checks, dataset versioning, signing, and controlled ingestion gates to the AI lifecycle so corrupted or unauthorised data cannot silently reshape model behaviour. Treat training inputs and model artefacts as security-sensitive assets that require tamper evidence.
• Baseline AI behaviour and alert on deviations Establish behavioural baselines for outputs, token usage, prompt patterns, and downstream API calls so security teams can distinguish expected model evolution from malicious manipulation. Feed those signals into security operations workflows rather than leaving them inside MLOps tooling.
• Run adversarial testing against real enterprise use cases Test the highest-risk models and agents against prompt injection, data poisoning scenarios, and identity abuse paths that reflect actual business workflows. Focus red teaming on where AI can influence decisions or reach data rather than on abstract benchmark performance.

Key takeaways

• AI risk in enterprises now combines model manipulation with identity and data governance gaps, which means conventional security controls only cover part of the problem.
• The article's strongest evidence is that over-scoped AI access materially increases incident likelihood, while weak visibility leaves organisations unable to distinguish benign model drift from malicious activity.
• Security teams should prioritise least-privilege AI access, provenance controls, and behavioural monitoring before expanding autonomous use cases further.

Key terms

• Adversarial Machine Learning: Adversarial machine learning is the deliberate manipulation of inputs, training data, or feedback so an AI model behaves in an attacker-chosen way. The issue is not broken infrastructure. It is that the model can remain functional while its decisions become unreliable, unsafe, or biased.
• Data Poisoning: The deliberate or accidental contamination of a data source that influences system behaviour. In AI environments, poisoned content can alter retrieval results, generated answers, or downstream decisions, which makes write access, change monitoring, and source integrity part of the identity control problem.
• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
• AI Access Sprawl: AI access sprawl is the uncontrolled growth of permissions, data reach, and tool access granted to AI systems over time. It usually appears when teams add integrations faster than they document ownership, review privileges, or define a clean revocation path.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners build the identity controls that AI programmes now depend on.