Notifications
Clear all
Topic starter
15/08/2026 6:12 pm
TL;DR: AI applications now create distinct attack paths through prompt injection, data leakage, token compromise, and identity spoofing, according to Obsidian Security, while Gartner says 75% of enterprises will have deployed AI applications in production by the end of 2025. The security gap is no longer theoretical: access, telemetry, and authorization models must be redesigned for dynamic AI behaviour, not static software assumptions.
NHIMG editorial — based on content published by Obsidian Security: AI Application Security: Safeguarding Data, Code, and Behavior
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Obsidian Security's analysis of AI application security and agent runtime risk →
AI application security and agent access: are your controls keeping up?
Explore further
15/08/2026 6:19 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI application security now depends on identity and runtime control
