TL;DR: AI security failures now surface at runtime through prompt injection, tool misuse, data leakage, and model extraction, according to AccuKnox, which argues that NIST AI RMF, OWASP LLM Top 10, and EU AI Act requirements only matter when they are enforced continuously. The operational shift is from point tools and questionnaires to a lifecycle control plane that ties inventory, policy, monitoring, and audit evidence together.
At a glance
What this is: AccuKnox argues that enterprise AI security failures in 2026 are runtime problems, with prompt injection, tool misuse, leakage and extraction demanding continuous controls rather than bolt-on review.
Why it matters: For IAM, NHI and AI security teams, this matters because AI systems combine identities, permissions, data and actions in one runtime path, so governance has to move to the point of use.
By the numbers:
- AI-related incidents reached 233 in 2024, a 56.4% year-over-year increase.
- AI adoption moved from 55% of organisations in 2023 to 78% in 2024.
- Among organisations compromised in AI model or application breaches, 97% lacked proper AI access controls.
Context
AI security is now a runtime governance problem, not just a model-testing problem. The control gap appears when prompts, tools, datasets and permissions converge inside live workflows, because the decision to act often happens after the build phase has ended.
That matters for identity practitioners because AI systems behave like policy-bearing software that can call tools, access data and trigger downstream action. When the identity of the system is not governed at runtime, conventional review, AppSec and GRC checks miss the point where abuse actually occurs.
Key questions
Q: How should security teams stop prompt injection from turning into tool misuse?
A: They should enforce authorization at the tool or resource boundary, not inside the model. Scope each tool to the minimum necessary permission, then deny any call that falls outside that scope. Prompt filtering still has value, but it cannot be the last line of defence because the model is exactly what the attacker is trying to influence.
Q: Why do AI applications create access control risk even when the underlying model is not compromised?
A: AI applications can still expose data when retrieval, prompts, or agent actions are allowed to operate beyond the original business need. The model may appear trustworthy while the surrounding application fetches sensitive content, inherits excessive permissions, or returns information the user should not see. The risk sits in the orchestration layer and its authorization design.
Q: What do security teams get wrong about AI access risk?
A: Many teams focus on the model while ignoring the identity path that reaches it. If a service account or token can invoke AI infrastructure, then that credential becomes the real control point. The mistake is treating AI risk as a model problem instead of an access governance problem.
Q: How can organisations prove their AI controls are actually working?
A: Look for evidence that policy decisions are logged, sensitive prompts are being redacted or blocked when required, and approved AI interactions are traceable by identity and business context. Effective programmes produce audit-ready records, not just policy text. If the control cannot explain what happened in a session, it is not operational enough.
Technical breakdown
Why prompt injection becomes a runtime control failure
Prompt injection works because untrusted text is treated as if it were instruction-bearing context. In an agentic flow, the model may retrieve, summarise or act on adversarial content before any human sees the result, and tool permissions can turn that semantic manipulation into real system action. The failure is not the existence of a bad prompt alone, but the absence of a boundary between trusted policy and untrusted input. Runtime filtering, context isolation and tool-call constraints are the control layer that determines whether the model merely reads hostile content or executes it.
Practical implication: enforce context isolation and policy checks at inference time, not after outputs are generated.
How model extraction and data leakage exploit inference paths
Model extraction is a high-volume probing problem, while leakage is often a boundary problem. Attackers can query an endpoint until the system reveals enough behavioural pattern to clone capability, or they can coerce outputs, embeddings or retrieval results into exposing data that should never have been available to that session. Because AI systems bridge data access and content generation, the security question is not just who can call the model, but what the model can reveal through normal operation. Data fencing, output controls and logging are therefore identity-adjacent controls as much as they are AI controls.
Practical implication: restrict what each AI workload can read and return, and log inference activity as a governed access event.
Why AI security needs a lifecycle control plane
A lifecycle control plane is the operating model that connects discovery, policy, runtime enforcement, continuous validation and evidence. In practice, that means inventorying models, prompts, tools, datasets and endpoints, then binding them to approved policy and monitoring. This is more than architecture. It is what allows risk owners, platform teams and GRC to see the same control state instead of fragmenting responsibility across disconnected tools. The article’s core point is that AI security becomes manageable only when governance is enforced at the point where the system acts, not only where it is built.
Practical implication: build one control plane for AI assets, policy and evidence, then use it as the source of truth for runtime governance.
Threat narrative
Attacker objective: The attacker aims to make the AI system perform unsafe actions or reveal information while appearing to operate within normal user-facing workflows.
- Entry typically begins with indirect prompt injection or unsafe tool invocation, where untrusted content is introduced into the model’s working context.
- The attacker then abuses the model’s tool and permission chain to trigger actions, reveal data or amplify access beyond the original user intent.
- Impact follows as data leaks, unauthorized workflow execution, model behaviour manipulation or extraction of proprietary capability.
Breaches seen in the wild
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
- McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
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
Runtime enforcement is now the decisive AI governance control. AI systems fail where policy meets execution, not where policy is written. Static questionnaires and one-time assurance cannot contain prompt abuse, unsafe tool use or leakage once a model is live. The practical conclusion is that security governance has to move into the runtime path that decides whether the system may act.
AI security is an identity problem as much as a model problem. The article correctly shows that AI touches identities, entitlements, secrets and data in one chain. That means access scope, tool authorization and dataset permissions are not adjacent controls; they are the mechanism that determines whether the model can be trusted to operate. Practitioners should treat AI workloads as governed identities with bounded authority.
Continuous evidence is becoming the new assurance model. NIST AI RMF, OWASP LLM Top 10 and EU AI Act obligations only become operational when controls are measurable and auditable. That shifts assurance from periodic review to live evidence of policy enforcement, detection and containment. The result is a governance model that can survive regulatory scrutiny and internal challenge.
Prompt injection is really a control-plane trust gap. The memorable failure mode here is untrusted context becoming trusted action. That is the specific governance assumption the article exposes: that the system can safely interpret outside text without runtime mediation. In practice, teams need to close the gap between content ingestion and tool execution before the model can convert hostile instructions into action.
AI security debt accumulates when teams bolt controls onto the wrong layer. AppSec-only, CloudSec-only and GRC-only operating models each miss part of the chain. The discipline now is to govern AI as a runtime service with explicit ownership, evidence and containment. That is how the field moves from reactive alerting to defensible control.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
- Read next: Agentic AI Security Guide
What this signals
AI security debt is now an operational issue, not a roadmap item. The useful unit of control is the runtime session, because that is where prompts, tools, data and permissions converge into an action. If teams cannot observe and constrain that session, they are managing AI risk by assumption rather than by control.
Runtime control turns AI governance into an access problem that identity teams can own. That is the important bridge for IAM and PAM leaders: the question is no longer only who signed off on the model, but what the model is allowed to do once it is live. Access scope, tool authority and data reach become the decisive governance variables.
For practitioners
- Inventory AI assets and permissions Map models, endpoints, datasets, vector stores, tools and the identities they use so every runtime path has an owner and a policy boundary.
- Enforce runtime tool-call policy Require allowlisted tools, parameter validation and context isolation before an agent can act on untrusted content or external retrieval results.
- Bind AI controls to audit evidence Record policy violations, data access events and model actions in logs that GRC and SOC can use as continuous assurance evidence.
- Red-team the inference path regularly Test prompt injection, extraction, poisoning and unsafe-success scenarios after every material change to prompts, tools, models or data.
- Tighten sensitive data fencing Default deny access to high-value datasets, restrict outputs where needed and prevent retrieval from widening exposure beyond approved use.
Key takeaways
- AI security failures now emerge when runtime context, tool permissions and data access combine inside live workflows.
- The strongest evidence in the article is that controls must be enforced continuously, because policy documents do not stop prompt-driven abuse on their own.
- For practitioners, the priority is to treat AI systems as governed runtime identities with bounded action, auditable evidence and constrained reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack surface, NIST AI RMF and NIST CSF 2.0 set the technical controls, and EU AI Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Tool misuse is central to the article's runtime abuse and agent control discussion. |
| ASI03 — Identity & Privilege Abuse | The article repeatedly ties AI risk to overbroad permissions and runtime authority. | |
| Recommendation — Enforce tool-call policies so agent actions stay within approved parameters and context. Constrain agent identity and privilege so AI systems cannot exceed their intended authority. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article maps operational controls to NIST AI RMF governance and evidence needs. |
| MEASURE — AI Measurement and Monitoring | Continuous validation and monitoring are presented as core control requirements. | |
| Recommendation — Define AI ownership, approval and accountability before allowing runtime deployment. Measure runtime behaviour, policy violations and drift continuously instead of relying on periodic review. | ||
| EU AI Act | Art. 9 — Risk management system | The article explicitly discusses EU AI Act readiness, risk-tiering and audit-ready evidence. |
| Recommendation — Build a documented risk-management system that produces evidence for AI governance and assurance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article treats AI runtime permission scope as a primary security control. |
| Recommendation — Apply least-privilege authorization to AI agents, tools and data paths. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Prompt-driven abuse and leakage map to credential access and exfiltration behaviour. |
| Recommendation — Map AI abuse paths to credential access and exfiltration tactics to improve detection coverage. | ||
Key terms
- Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
- 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-SPM: AI Security Posture Management extends security visibility into AI models, prompts, outputs, and supporting workflows. It gives teams a way to identify risky AI usage, check policy alignment, and monitor how AI systems interact with data and identity controls over time.
- Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
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 security and identity teams build the governance habits needed when systems act with delegated authority.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org