Because AI systems often act through delegated access. When a model can use tools, retrieve data, or trigger actions, it becomes a runtime decision-maker with privileges that can be misused through prompt injection, poisoned context, or overbroad permissions. That is an identity problem as much as a code problem.
Why This Matters for Security Teams
Traditional AppSec assumes the main risk is untrusted input affecting application logic. AI systems change that model because the prompt, retrieved context, and tool outputs can all influence runtime behaviour. When an AI assistant can read tickets, query knowledge bases, or execute workflows, it is operating with delegated authority. That makes identity, privilege, and accountability central to security design, not just software hardening.
Security teams often miss that the highest-risk failure is not a classic code exploit but an authority boundary failure. A model may be technically well secured while still being able to access far more data or actions than it needs. Guidance from the NIST Cybersecurity Framework 2.0 is useful here because it frames governance, protection, detection, response, and recovery as continuous capabilities rather than one-time checks. In practice, many security teams encounter identity risk only after an AI agent has already over-read data or over-reached its permissions, rather than through intentional design review.
How It Works in Practice
AI systems create identity and access risk because they operate through a chain of trust. The user, the model, the retrieval layer, and the connected tools may each have different permissions, but the model can influence how those permissions are exercised. That means a prompt injection issue can become an authorisation issue if the agent is allowed to disclose records, modify tickets, send emails, or approve actions without sufficient checks.
Operationally, the main control question is not only “can the model answer this?” but “what can it do, on whose behalf, and under what constraints?” The OWASP Non-Human Identity Top 10 is relevant because many AI services behave like non-human identities: they need scoped credentials, rotation, auditability, and lifecycle control. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to this pattern, especially around access enforcement, least privilege, logging, and separation of duties.
- Give the AI system a distinct service identity rather than sharing human credentials.
- Scope tool access to the minimum data sets and actions needed for the use case.
- Require human approval for high-impact actions, especially writes, payments, and deletes.
- Log prompts, retrieved context, tool calls, and resulting actions for forensic review.
- Validate outputs before execution when the response can trigger downstream change.
This guidance tends to break down in highly dynamic agentic environments where permissions are assembled on the fly and toolchains change faster than policy reviews can keep pace.
Common Variations and Edge Cases
Tighter access controls often increase friction and reduce autonomy, requiring organisations to balance usability against the risk of silent overreach. That tradeoff becomes more visible when teams want an AI agent to operate across multiple systems with minimal human intervention.
Current guidance suggests that not all AI deployments need the same identity model. A read-only chatbot has a very different risk profile from an agent that can create records, move funds, or deploy code. Best practice is evolving, but a sensible pattern is to classify AI use cases by impact, then assign permissions, monitoring, and approval steps accordingly. Where the model is only summarising text, identity controls may focus on data access and retention. Where the model can act, the security posture should look more like privileged access governance than ordinary application security.
Edge cases include shared service accounts, embedded credentials in workflows, and retrieval systems that surface sensitive data even when the model itself is not directly allowed to store it. The security boundary is often weaker than teams assume because the model can cause data exposure indirectly through a tool call or generated instruction. That is why identity review must include the full agent path, not just the front-end application. Where autonomy increases and exception handling is informal, identity and access controls usually fail at the integration points rather than inside the model itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | AI agents need access rights limited to their intended functions. |
| OWASP Non-Human Identity Top 10 | AI services often function as non-human identities with credentials and lifecycle risk. | |
| NIST AI RMF | AI RMF is relevant because the issue is model behaviour and governance, not only code. | |
| MITRE ATLAS | AML.TA0002 | Prompt injection and poisoned context can manipulate AI behaviour and tool use. |
Model adversarial inputs and test whether they can redirect prompts, retrieval, or tool actions.
Related resources from NHI Mgmt Group
- Why do AI systems create identity and data risk beyond the model itself?
- Why do AI agents create a different access-risk profile than traditional applications?
- When does AI create more governance risk than traditional data systems?
- Why do conversational AI systems create new identity and access risks?
