Cybersecurity in AI exposes gaps in identity and access controls

At a glance

What this is: This is an analysis of how AI changes enterprise cybersecurity, with the core finding that identity-centric controls, continuous monitoring, and policy enforcement must extend into AI and SaaS environments.

Why it matters: It matters because IAM, IGA, PAM, and security architecture teams now have to govern non-human access patterns that can cross applications, data sets, and runtime decisions faster than human review cycles can respond.

By the numbers:

• 75% of organizations will have deployed AI applications in production by the end of this year, yet fewer than 30% have implemented AI specific security controls.

👉 Read Obsidian Security's analysis of cybersecurity in AI and SaaS protection

Context

AI cybersecurity is the discipline of protecting artificial intelligence systems, machine learning models, and AI-powered applications from compromise, misuse, and data leakage. In this article, the primary governance problem is that AI systems increasingly act as non-human identities with broad access to SaaS platforms, APIs, and sensitive data, while many security programmes still treat them as extensions of existing application controls.

That gap becomes more visible when AI systems can query multiple services, trigger workflows, and move data at machine speed. The article argues that identity, access, and monitoring controls must be applied across human users, service accounts, and AI-driven workloads because the failure mode is not just malicious input, but excessive privilege and weak runtime governance.

For background on the identity side of this problem, the concepts behind [OWASP NHI Top 10](https://nhimg.org/complete-guide-to-the-2026-owasp-top-10-risks-for-agentic-applications) and the [Ultimate Guide to NHIs](https://nhimg.org/the-ultimate-guide-to-non-human-identities#key-challenges-and-risks) are directly relevant.

Key questions

Q: How should security teams govern AI tools that connect to SaaS data?

A: Treat each AI tool as a non-human identity with an owner, a defined scope, and an expiry path. Require approval for every new integration, limit access to the minimum necessary SaaS objects, and review delegated permissions on a recurring schedule. Governance fails when consent is treated as a one-time event instead of a lifecycle.

Q: Why do AI agents create more identity risk than ordinary SaaS integrations?

A: AI agents can operate continuously, chain multiple tools, and act on delegated permissions with little human oversight. That makes their effective privilege broader than the original approval suggests. The risk is not only access, but the speed and persistence with which the agent can turn access into credential exposure or lateral movement.

Q: What breaks when AI apps are allowed to run under broad credentials?

A: Least privilege breaks first, because the app can access more than the initiating user should reach directly. Then traceability weakens, because security teams can no longer tell whether the action came from the user, the model, or the integration. Broad credentials turn a convenience layer into a delegated control plane.

Q: Who should be accountable for AI access decisions in identity programmes?

A: Accountability should sit with the identity or application owner who can justify the entitlement and revoke it when needed. Each AI permission should be linked to an accountable identity so certification, investigation, and audit can trace decisions back to a responsible owner.

Technical breakdown

Prompt injection and model poisoning in enterprise AI

Prompt injection manipulates model behaviour through crafted inputs, while model poisoning corrupts training or fine-tuning data so the system learns unsafe or biased behaviour. In both cases, the attack targets the decision layer rather than the perimeter. That matters because a model that appears to be functioning normally can still be issuing unsafe outputs, leaking data, or taking disallowed actions once the poisoned logic is triggered.

Practical implication: security teams need adversarial testing and data provenance checks before relying on AI outputs in production.

Token compromise and AI service account abuse

AI systems commonly rely on API tokens, service accounts, and other non-human credentials to reach data and tools. If those credentials are stolen or over-scoped, the attacker does not need to break the model itself. They can operate through legitimate access paths, which makes the compromise look like approved automation unless identity telemetry is monitored closely.

Practical implication: treat AI credentials as governed NHI assets with rotation, revocation, and usage monitoring.

Dynamic authorization for AI workloads across SaaS

Static permissions break down when an AI system needs different access depending on user, data sensitivity, time, or environment. The article points to role-based, attribute-based, and policy-based access control as the mechanism for runtime decisions, with zero trust extending verification to every request. The real architectural shift is from provisioning access once to evaluating access continuously as the AI system operates across applications.

Practical implication: align AI access policies to runtime context instead of assuming one role can safely cover all tasks.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI functionality into a high-volume access path for data theft, workflow manipulation, or persistent internal abuse.

1. Entry occurs when attackers manipulate AI behaviour through prompt injection or compromise API tokens and service accounts that the system uses to reach SaaS data and tools.
2. Escalation happens when the compromised AI path inherits broad permissions, allowing the attacker to query multiple systems, move through connected applications, and reuse legitimate access patterns.
3. Impact follows when the AI system exfiltrates sensitive data, alters business logic, or persists as a trusted backdoor inside enterprise workflows.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security is now an identity governance problem, not just a model safety problem. The article shows that the real exposure sits at the intersection of identity, authorization, and data movement across SaaS and AI systems. Security teams that treat AI as a separate technical silo miss the operational fact that AI access is still access, and it must be governed like any other privileged non-human workload. The implication is that IAM and security architecture must converge around the same control plane.

Prompt injection succeeds because trust is still implicit inside many AI workflows. The security model assumes that user input, model output, and downstream action can be separated cleanly. That assumption fails when the system can interpret untrusted text and then act on it through connected tools, because the decision path becomes part of the attack surface. Practitioners need to stop treating model output as harmless until proven otherwise.

Token compromise is the clearest NHI failure mode in AI environments. API keys and service accounts remain the easiest bridge from AI logic into enterprise data, especially when rotation, scoping, and revocation are inconsistent. This is not a new control problem, but AI amplifies it because the credential often belongs to a system that can process data faster and more broadly than a human user ever could. The practitioner conclusion is that AI credentials need the same lifecycle discipline as the most sensitive machine identities.

Zero trust only becomes meaningful for AI when every request is re-evaluated at runtime. The article’s emphasis on dynamic policy evaluation reflects a broader market shift away from static entitlements. AI systems that move across multiple SaaS platforms cannot be safely governed by one-time provisioning decisions alone, because the request context changes continuously. The implication for practitioners is that policy must be bound to task, time, and context rather than role alone.

Continuous monitoring is the control that turns AI from opaque behaviour into governable behaviour. Behavioural analytics, anomaly detection, and SIEM integration matter because legitimate AI traffic can resemble reconnaissance or exfiltration. The field should stop asking whether AI behaves unusually and start asking whether the organisation can explain that behaviour fast enough to contain it. For security teams, observability is the difference between a logged event and a managed incident.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same survey.
• For a broader control baseline, see the Ultimate Guide to NHIs for the visibility and governance issues that consistently appear before escalation.

What this signals

Ephemeral agent oversight debt: enterprises are increasing AI deployment faster than they are building the lifecycle controls needed to govern those identities. That gap will widen first in SaaS environments, where delegated access, app-to-app movement, and poorly scoped tokens create quiet exposure before any obvious alert fires.

The immediate programme impact is that identity teams need to align AI governance with existing NHI processes rather than creating a separate exception path. That means inventory, ownership, attestation, and revocation must apply to AI systems with the same discipline used for other privileged machine identities.

For teams building the control baseline, [OWASP NHI Top 10](https://nhimg.org/complete-guide-to-the-2026-owasp-top-10-risks-for-agentic-applications) and the [Ultimate Guide to NHIs](https://nhimg.org/the-ultimate-guide-to-non-human-identities#key-challenges-and-risks) are the most relevant internal references because they frame the same sprawl and access problems from different angles.

For practitioners

• Map AI systems to named identity owners Assign a business and technical owner to every AI system, service account, and API token so the credential lifecycle is not lost inside platform teams or shadow deployments.
• Rotate and revoke AI credentials on a fixed schedule Automate rotation for API keys and tokens, then verify immediate revocation paths for decommissioned agents, failed experiments, and compromised integrations.
• Enforce runtime policy for AI-to-SaaS access Use policy-based access decisions that consider data sensitivity, request context, and destination system rather than giving AI workloads one broad role across all applications.
• Baseline AI behaviour and alert on drift Track API call volume, data access patterns, and execution times so unexpected spikes or unusual destinations can be investigated before data leaves the environment.
• Test AI workflows for prompt injection and token abuse Red-team the input layer and the credential layer together, because both are viable entry points for misuse of AI systems in production SaaS environments.

Key takeaways

• AI security fails fastest when identity controls lag behind deployment, because the attack surface is defined by what the system can access, not only by what it can model.
• Credential abuse and prompt injection are complementary risks, and both can move an AI system from useful automation to a trusted internal access path.
• The practical response is to govern AI as NHI, with ownership, runtime authorization, lifecycle controls, and continuous monitoring built into the operating model.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• AI Service Identity: An AI service identity is a machine credential that allows a model, agent, or supporting workflow to authenticate to tools, data sources, or APIs. It behaves like a non-human identity because it can be issued, scoped, monitored, and revoked independently of any person.
• Dynamic Authorization: Dynamic authorization is an access model that makes the trust decision at request time using current identity and context. It replaces reusable stored credentials with short-lived, policy-scoped tokens issued only after the workload proves itself.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

What's in the full article

Obsidian Security's full article covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of AI authentication patterns across SaaS platforms and API-based integrations.
• Concrete examples of runtime policy enforcement, anomaly detection, and incident response telemetry.
• Implementation guidance for aligning AI security with zero trust, compliance, and audit requirements.
• Configuration examples and architecture notes for teams extending existing security stacks into AI workflows.

👉 The full Obsidian Security article covers AI threat vectors, identity controls, and deployment guidance in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.