TL;DR: AI risks in generative systems emerge from prompt injection, data leakage, hallucinations, poisoned context, and over-permissioned tool use, according to Akto. Those failure modes become identity problems as soon as AI systems can access data, credentials, or enterprise APIs without tight governance.
NHIMG editorial — based on content published by Akto: AI Risks Explained: Major Threats, Attack Surfaces and Mitigation Strategies
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
Questions worth separating out
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.
Q: Why do AI agents make non-human identity governance harder?
A: AI agents make governance harder because they can request tools, act autonomously, and change behaviour across sessions while still relying on machine credentials.
Q: How do security teams know whether AI access is actually working safely?
A: Look for three signals: complete discovery of the AI estate, clear mapping of source data to each system, and logs that prove what was accessed and why.
Practitioner guidance
- Separate instruction, retrieval, and execution controls Inspect every AI workflow for places where natural-language input can influence tool use, database queries, or downstream automation.
- Scope every agent to a task-bound identity Assign each AI agent the minimum permissions needed for a single workflow and remove standing access wherever practical.
- Audit AI access like any other privileged identity Log prompts, retrieved documents, tool calls, and final outputs so you can reconstruct what the agent saw and what it did.
What's in the full article
Akto's full blog covers the operational detail this post intentionally leaves for the source:
- Concrete examples of prompt injection, indirect injection, and RAG poisoning in production AI workflows
- Implementation guidance for securing tool calling, API access, and output handling in agentic systems
- Operational controls for logging prompts, model outputs, and retrieval events for investigation and audit
- Mitigation patterns for reducing agent autonomy without breaking business workflows
👉 Read Akto's analysis of AI risks in generative systems and agentic workflows →
AI risk in generative systems: what IAM teams are missing?
Explore further
AI risk management is now identity governance by another name. The article correctly shows that the most dangerous GenAI failures are not limited to model inaccuracies. They arise when AI systems are allowed to interpret untrusted context and act through connected tools, which makes authorisation, delegation, and auditability the real control plane. For IAM and PAM teams, the practical conclusion is that AI security cannot be bolted on after deployment.
A question worth separating out:
Q: Who is accountable when an AI agent accesses the wrong data?
A: Accountability sits with the team that defined the agent’s scope, the owner of the delegated user context, and the operators who allowed access to persist beyond the task. For customer workflows, audit logs should show both the agent and the user identity so responsibility can be traced clearly.
👉 Read our full editorial: AI risk in generative systems is really identity risk