TL;DR: AI systems now face prompt injection, data poisoning, leakage, and autonomous tool abuse, and Akto’s guide argues that traditional IT risk methods are too static for agentic environments. The real shift is that AI governance now depends on continuous monitoring, adversarial testing, and identity-aware access control, not just pre-launch review.
At a glance
What this is: Akto’s guide frames AI risk management as a lifecycle discipline for AI systems, with particular focus on prompt injection, data poisoning, data leakage, and the need for continuous guardrails.
Why it matters: For IAM, NHI, and security teams, the key message is that agentic AI governance cannot stop at model review because access, delegation, and tool use create identity and privilege risk at runtime.
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
👉 Read Akto's guide to AI risk management frameworks for agentic systems
Context
AI risk management has moved from a governance discussion to an operational control problem. Once AI systems can read data, call APIs, and act inside workflows, the question is no longer whether the model is accurate, but whether it is safely bounded, continuously monitored, and accountable across its lifecycle. That makes AI risk management directly relevant to IAM, NHI governance, and agentic AI security.
Akto’s article usefully reflects a wider industry shift: static risk review is failing because AI behaviour changes after deployment, and agents can combine prompts, data, and tools in ways traditional controls do not anticipate. The identity bridge is obvious here. Every agent that authenticates to a database, cloud service, or business application is effectively operating as a non-human identity and needs lifecycle, privilege, and audit controls that match its runtime behaviour.
Key questions
Q: How should security teams govern AI models that can call tools and access data?
A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.
Q: Why do AI agents create a different access-risk profile than traditional applications?
A: AI agents can chain actions, call multiple tools, and change behaviour based on context, so one credential can enable more than one operational path. That means the risk is not just whether the agent authenticates, but how far it can move once inside. The key measure is privilege scope, not token count.
Q: What do teams get wrong about AI guardrails and identity controls?
A: They often assume a content filter is a substitute for access governance. It is not. Guardrails reduce unsafe responses after the session has started, but they do nothing to limit who can reach the system, what data sources the agent can query, or whether delegation is over-broad.
Q: Who is accountable when an AI system moves data outside policy?
A: Accountability should sit with the team that owns the AI workflow, the data it touches, and the credentials that enable it. If governance stops at authentication, ownership becomes blurred. Clear accountability means mapping the data path, the action scope, and the approving function before deployment.
Technical breakdown
Why traditional risk frameworks miss AI agent behaviour
Traditional IT risk frameworks assume systems are comparatively stable: access paths are known, execution is predictable, and controls can be validated against fixed states. Agentic AI breaks those assumptions because it can interpret ambiguous input, decide when to call tools, and change behaviour as context changes. That means the real risk surface includes prompts, retrieval sources, connected APIs, and output handling. Prompt injection is especially important because a malicious instruction can redirect an agent without modifying code. For identity teams, the issue is not just model safety. It is whether an AI system has rights to perform actions that exceed the task it was meant to complete.
Practical implication: map every AI system to the data, tools, and credentials it can use before granting production access.
How AI guardrails work across inputs, outputs, and tool use
Guardrails are policy checks placed around the model rather than inside it. They can screen prompts for malicious instructions, validate model outputs before release, and constrain which tools an agent can call. In practical terms, this is closer to runtime authorisation than classical malware detection. A useful guardrail model separates safe inference from privileged execution, so that an AI response does not automatically translate into an action. For NHI governance, that matters because an agent with database or SaaS access can become a high-risk identity if its output is allowed to trigger transactions, changes, or data retrieval without secondary controls.
Practical implication: require policy checks before tool execution, not only after the model has produced a response.
Why continuous monitoring matters more than one-time validation
AI systems drift because data changes, prompts evolve, connected tools expand, and attackers adapt. Continuous telemetry gives teams evidence on input patterns, policy violations, abnormal outputs, and repeated attack attempts. That is different from periodic testing, which only shows whether a system was safe at one point in time. In governance terms, monitoring becomes the control that connects model risk, security operations, and audit readiness. For agentic systems, logs should show what the agent saw, what it decided, which tool it used, and what action followed. Without that chain, incident response becomes guesswork rather than containment.
Practical implication: retain decision, tool-call, and policy-violation telemetry so agents can be investigated like privileged identities.
Threat narrative
Attacker objective: The attacker wants to steer the AI system into disclosing sensitive information or performing privileged actions on their behalf.
- Entry occurs when a user crafts malicious prompts or hidden instructions that influence an AI system’s decision path without changing the underlying code.
- Escalation happens when the agent follows those instructions into connected tools, APIs, or data stores that exceed the intended task boundary.
- Impact follows when the agent leaks private data, executes unintended actions, or produces corrupted outputs that affect business operations.
NHI Mgmt Group analysis
AI risk management has become an identity governance problem as much as a model risk problem. Once an AI system can authenticate to services, call tools, and take actions, it behaves like a non-human identity with its own lifecycle and privilege profile. That is why conventional application testing is insufficient on its own. IAM and PAM teams need to treat agents as governed actors, not just software features. The practical conclusion is that AI security programmes must inherit identity controls, not sit beside them.
Prompt injection is really a delegation failure. The article correctly points to malicious inputs, but the deeper issue is that many agent deployments allow language to become authority. If a prompt can trigger a tool call without a separate trust decision, then the system has converted text into privilege. That is a governance gap, not simply a content-safety problem. The practitioner takeaway is to separate interpretation from execution so delegated actions require explicit policy approval.
AI governance debt is building faster than most organisations can inventory it. The hardest part of the article’s lifecycle message is that shadow AI, unclassified agents, and undocumented connectors create risk faster than teams can catalogue them. This is where the named concept matters: AI governance debt is the accumulation of unmanaged models, prompts, tools, and credentials that future controls must untangle. The conclusion is that inventory and ownership are now first-order security controls.
Continuous monitoring must extend into identity telemetry for AI systems. The article emphasises telemetry, and that is the right direction, but monitoring only works when it captures who or what the agent authenticated as, what it accessed, and which action chain followed. In other words, AI observability without identity context is incomplete. Teams should align AI monitoring with NIST AI RMF governance and map privileged AI actions to familiar identity review and audit processes.
Security teams should stop treating agent autonomy as a binary. The article notes that some agents are more autonomous than others, but the operational question is how much authority each workflow is allowed to exercise before human or policy intervention. That is the same question IAM and PAM have always asked about privilege, now applied to non-human actors. The conclusion is to scope every AI agent by authority, not just by model type.
What this signals
AI governance debt: the fastest-growing exposure in agentic programmes is not model failure alone, but the accumulation of undocumented agents, connectors, and credentials that no one can confidently govern. That makes inventory, ownership, and policy enforcement the control stack that determines whether AI expands safely or quietly widens the attack surface.
Organisations should expect AI security work to converge with identity governance, because the practical question is no longer only what the model knows, but what it can access and do. The most mature programmes will align agent telemetry with access reviews, privilege boundaries, and incident workflows so that agent decisions can be audited like any other high-risk identity event.
For practitioners
- Define an AI identity inventory List every LLM, agent, RAG pipeline, and AI-powered workflow, then record the data sources, tools, and credentials each one can reach. Link ownership to a named service team so unclassified systems do not become shadow AI.
- Separate inference from execution Require policy checks before an agent can call APIs, write data, or trigger business actions. If the output is sensitive, route it through a control layer that can block prompt injection and validate intent before execution.
- Instrument identity-rich telemetry Log the agent principal, tool calls, data sources, policy decisions, and downstream actions so investigations can reconstruct the full decision chain. Use those logs for both incident response and audit evidence.
- Apply risk scoring to agent authority Classify agents by data sensitivity, autonomy, and blast radius, then assign stronger review and testing to any system that can access regulated data or take irreversible actions.
Key takeaways
- AI risk management is now a governance problem for both models and the identities they use to act in enterprise systems.
- Static validation is insufficient when agents can change behaviour, call tools, and create new attack paths after deployment.
- The strongest control model combines inventory, execution-time policy checks, and identity-rich telemetry for every agent.
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 address the attack surface, NIST AI RMF, NIST CSF 2.0 and NIST AI 600-1 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN | The article is centered on AI governance, accountability, and lifecycle risk management. |
| OWASP Agentic AI Top 10 | Prompt injection and tool abuse are core agentic AI risks discussed in the article. | |
| NIST CSF 2.0 | GV.OV-01 | The article stresses ongoing governance, monitoring, and accountability for AI systems. |
| NIST AI 600-1 | The article discusses GenAI risk patterns, guardrails, and evaluation practices. | |
| ISO/IEC 27001:2022 | A.5.15 | Access control matters where AI systems connect to data, APIs, and business workflows. |
Assign named owners and governance review for each AI system before it reaches production.
Key terms
- NIST AI Risk Management Framework: A voluntary framework for organizing AI risk governance around clear outcomes rather than fixed compliance steps. It helps enterprises define accountability, map AI context, measure risk, and manage treatment, but it does not itself provide enforcement or certification.
- 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.
- Guardrails: Guardrails are policy controls that inspect prompts and model outputs against defined safety, privacy, and compliance rules. In AI operations, they reduce harmful language and disclosure risk, but they do not replace entitlement management, logging, or identity governance for the systems that call the model.
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
What's in the full article
Akto's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step AI inventory and classification workflow for LLMs, RAG pipelines, and agentic features.
- Practical examples of prompt injection testing, red teaming, and guardrail placement across AI workflows.
- Monitoring and audit-readiness guidance for tracking inputs, outputs, policy violations, and abnormal model behaviour.
- Framework comparisons across NIST AI RMF, ISO/IEC 42001, and OECD AI Principles for programme owners.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security and identity practitioners a practical foundation for controlling non-human access in modern programmes.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org