AI application security now depends on identity and runtime control

At a glance

What this is: AI application security is shifting from code-centric protection to identity, data-flow, and runtime-behaviour control for LLMs, agents, and generative applications.

Why it matters: IAM, PAM, and NHI teams need to treat AI systems as active identities with scoped access, because compromised agents can access sensitive data, take unauthorized actions, and expand blast radius quickly.

By the numbers:

• According to Gartner, 75% of enterprises will have deployed AI applications in production by the end of 2025.
• 32% have implemented comprehensive AI security frameworks, works, creating a clear governance gap.

👉 Read Obsidian Security's analysis of AI application security and agent runtime risk

Context

AI application security is the discipline of protecting models, data flows, and runtime behaviour from misuse, leakage, and unauthorized action. In this article, the primary governance problem is that enterprises are deploying AI systems that can access data and execute actions before security teams have defined how those identities should be controlled.

That gap matters because AI agents are not passive software components. They can use credentials, touch sensitive systems, and behave differently from one session to the next, which means conventional application security and static IAM assumptions no longer cover the full risk surface.

The article’s starting point is typical of the current market: organisations are moving faster than their identity and monitoring controls can adapt. The result is a security model that protects code better than behaviour.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI models create more security risk than traditional applications?

A: AI models create more risk because they can be manipulated through prompts, poisoned data, and connected APIs, not just through code defects. Their behaviour also changes with context, which means access, data provenance, and runtime monitoring matter as much as static hardening.

Q: What breaks when AI agents rely on long-lived secrets and tokens?

A: Long-lived secrets create durable access paths that survive task completion, code changes, and even vendor compromise. If the secret is reused across workflows, one exposed credential can open several systems at once. The failure is not only exposure, but also delayed detection because the access still looks legitimate until someone traces the identity lineage.

Q: Who should own AI identity governance in the enterprise?

A: AI identity governance should be owned jointly by identity, security, and platform teams, with clear accountability for provisioning, monitoring, and revocation. If ownership sits only with one group, the organisation usually misses either the technical controls or the operational lifecycle. Shared governance is essential because the risk crosses IAM, NHI, and data access domains.

Technical breakdown

Why AI application security needs identity-aware authorization

AI applications do not just process input and return output. They often call APIs, query databases, and act on behalf of users or workloads, which means authorization has to evaluate both the request and the runtime context. RBAC alone is usually too coarse for this problem because an agent’s permitted action may depend on data sensitivity, session context, and the current trust posture of the requesting identity. That is why zero trust principles matter here: every request must be re-evaluated rather than assumed safe because it came from a previously trusted system.

Practical implication: treat every AI agent request as an authorization event, not a trusted continuation of the last one.

How prompt injection and identity spoofing expand the attack surface

Prompt injection is not just a model-quality issue. It is a control bypass technique that can cause an AI system to ignore intended boundaries and act on attacker-controlled instructions. Identity spoofing compounds the problem when agents rely on long-lived tokens or weak service-account boundaries, because the attacker does not need to break the model itself if they can induce the model to use its own privileges against the enterprise. In practice, the risky combination is instruction manipulation plus overprivileged access.

Practical implication: separate model behaviour testing from credential governance, because one without the other leaves a gap.

Why behavioral monitoring is central to AI runtime security

Static controls cannot fully describe dynamic AI behaviour, so runtime monitoring becomes the detection layer for abnormal access patterns. That means tracking unusual data volumes, unfamiliar endpoints, non-business-hour execution, and output patterns that suggest leakage or coercion. SIEM and SOAR integrations matter because they connect AI-specific signals to the organisation’s existing detection and response stack. The goal is not simply to log more, but to establish enough behavioural baseline to spot when an AI system has moved outside its normal operating envelope.

Practical implication: instrument agent activity for anomaly detection before you expand production access.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI system into an access multiplier that leaks data or performs unauthorized actions at enterprise scale.

1. Entry begins when an attacker uses prompt injection, compromised credentials, or an exposed integration to influence an AI application that already has enterprise access.
2. Escalation occurs when the AI system acts with overprivileged tokens or spoofed identity trust, allowing it to query data or trigger workflows beyond its intended scope.
3. Impact follows when the compromised AI system leaks sensitive data, approves fraudulent actions, or becomes a path into downstream enterprise systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 application security is now an identity governance problem, not just an application security problem. Once agents can touch data, invoke tools, and act on behalf of users, the control plane shifts from code integrity alone to who or what is authorised to act. That means IAM, PAM, and NHI governance have to be treated as core AI security controls rather than supporting functions. Practitioners should read AI security as identity architecture first.

Long-lived token trust is the named concept practitioners should stop normalising. The article shows how static credentials and persistent API access create durable attack paths for systems that behave dynamically. The issue is not only credential theft, but the assumption that a credential can safely outlive the intent that justified it. The practical conclusion is that privilege boundaries must be tied to runtime context, not just provisioning state.

Prompt injection becomes materially more dangerous when the target identity already has broad downstream access. The same malicious instruction has very different impact depending on whether the agent can reach production data, SaaS workflows, or internal APIs. That is why least privilege for AI systems is not a policy slogan, but a blast-radius control. Practitioners should treat access scope as the primary determinant of incident severity.

Static monitoring models are insufficient for AI behaviour that changes from one interaction to the next. Traditional alerting often looks for known bad patterns, but AI abuse frequently appears as subtle drift in volume, destination, or timing. Real-time behavioural baselining is therefore part of identity assurance for AI, not a separate observability project. Security teams should assume that without runtime telemetry, they are blind to agent misuse until after the damage is done.

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 report.
• Only 33% of organisations report AI agents have accessed inappropriate or sensitive data beyond their intended scope, which means most teams still lack clear runtime visibility.
• The operational next step is to pair identity governance with agent telemetry, as covered in OWASP NHI Top 10 and NIST AI Risk Management Framework.

What this signals

Long-lived access is becoming the weak point in AI governance. As agents move from pilot use into production workflows, the question shifts from whether they can be deployed to whether their access can be constrained and audited in real time. The governance model now has to assume that behaviour may change faster than review cycles can catch up, so runtime visibility becomes a baseline requirement rather than a maturity target.

AI security programmes will increasingly converge with NHI controls. When an agent can call tools, use tokens, and reach sensitive systems, it behaves like a governed non-human identity with a more volatile runtime profile. Teams should therefore align agent governance with identity lifecycle, access review, and privileged access processes instead of building a separate security island around AI.

Identity review cadences will need to measure use, not just entitlement. A privilege that looks acceptable on paper can still be unsafe if the agent uses it in unpredictable ways or far more broadly than expected. That is why the next generation of AI governance will depend on linking access scope, session telemetry, and policy enforcement into a single operational loop.

For practitioners

• Inventory AI identities and delegated access Create a register of every AI application, agent, service account, token, and external integration that can access production systems. Include owner, purpose, privilege scope, and data domains so you can see where AI access exceeds the intended use case.
• Replace long-lived credentials with time-bound access Move AI systems off static API keys where possible and use short-lived tokens, certificate-based trust, or tightly controlled federation. Revoke credentials that are not tied to a clear business function and review every token that can reach sensitive data.
• Add behavioural controls to existing SIEM and SOAR workflows Send AI application logs into your detection stack and build alerts for abnormal data volume, new endpoints, unusual execution windows, and sensitive output patterns. Use automated containment to suspend the agent before it can continue the same session path.
• Scope agent permissions to specific data domains Design access so an agent can only query the minimum data required for a bounded task. Use context-aware policy decisions to account for user session, data classification, and environment state before allowing a call to proceed.
• Test for prompt injection and model misuse before production expansion Run adversarial testing that simulates instruction override, data leakage, and spoofed identity behaviour across the full agent workflow. Validate both model behaviour and the downstream account permissions it can exercise.

Key takeaways

• AI application security now depends on governing agent identity, access scope, and runtime behaviour together.
• The risk is already visible in production, with AI systems using credentials and actions that traditional controls do not reliably contain.
• Enterprises need identity-centred telemetry and least-privilege design before AI usage expands further.

Key terms

• AI Application Security: AI application security is the discipline of protecting software that uses AI to make decisions, generate code, or interact with data and services. It goes beyond model safety to cover prompts, APIs, generated logic, runtime behaviour, and the permissions those components use in production.
• 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.
• Identity Spoofing: Identity spoofing is the use of false or stolen identity signals to make an AI system or its surrounding controls treat an untrusted actor as legitimate. In AI environments, it often combines with token abuse, weak service-account design, or poor trust boundaries.
• 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:

• Step-by-step identity and token control patterns for AI applications in SaaS and cloud environments
• Concrete examples of runtime monitoring signals for prompt injection, data leakage, and identity spoofing
• Implementation guidance for integrating AI logs into SIEM, SOAR, and ITDR workflows
• The article’s incident-response checklist for suspending a compromised agent and validating scope

👉 The full Obsidian Security article covers authentication patterns, runtime monitoring, and incident response 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 building or maturing an IAM or identity security programme, it is worth exploring.