Review scope and evidence labels
This page defines IAM for AI systems as the identity and access-management methodology for AI-enabled applications, agents, retrieval systems and supporting data flows.
Evidence labels used on this page:
- Official guidance — based on public official guidance such as CISA or NIST material.
- Community security guidance — based on public security community material such as OWASP.
- Author analysis — interpretation for AI security, architecture, governance and operational risk on this site.
- Implementation evidence required — local records that must exist before a control can be treated as operating.
This page is not a claim that a generic IAM product automatically secures AI. It is a Research methodology for asking the right identity and authorization questions.
Methodology snapshot
| Field | Value |
|---|---|
| Category | Identity, access control and AI trust boundaries |
| Research type | Methodology |
| Core question | Who or what is allowed to use which AI capability, data source, model, tool and output? |
| Main scope | Human users, service identities, agents, tools, APIs, model providers, datasets, indexes, logs and approvals |
| Useful outputs | Identity inventory, permission model, least-privilege design, access tests, audit records and exception handling |
| Companion methods | Zero Trust, RAG Security, AI Security Architecture, AI Governance, Audit Evidence |
| Review status | Public guidance reviewed; local design depends on identity provider, data classification and system capabilities |
What IAM for AI systems means
AI systems introduce identity questions that traditional application IAM may not make explicit: whose authority does an agent act under, which data can be retrieved, which tools can be called and which outputs can trigger workflow actions. Evidence: Official guidance; Author analysis.
For RAG systems, identity must travel into retrieval. A user should not receive restricted context simply because the index contains it. Evidence: Community security guidance; Author analysis.
For agentic systems, identity must also limit actions. The model should not become a privileged integration account with broad access to email, tickets, files or infrastructure. Evidence: Author analysis; Implementation evidence required.
What it is not
IAM for AI systems is not:
- only SSO on the chat interface,
- only an API key to a model provider,
- only role labels in a prompt,
- a reason to give agents administrator accounts,
- proof that retrieved data is authorized,
- a replacement for monitoring, approvals and audit evidence.
The practical goal is least privilege across users, agents, tools and data paths. Evidence: Official guidance; Author analysis.
Practical review checklist
| Area | Practical question | Evidence to retain |
|---|---|---|
| Human users | Which users can access which AI feature? | SSO/OIDC design, group mapping, access review |
| Agent identity | Does the agent have its own service identity or act on behalf of a user? | Identity model, delegation rules, token records |
| Retrieval | Are document and chunk permissions enforced at query time? | Permission mapping, negative tests, source metadata |
| Tools and APIs | Which tools can be called, with what scope and confirmation? | Tool allowlist, scopes, approval records |
| Model provider | Which data leaves the organisation and under which account? | Provider contract, routing rules, logging policy |
| Secrets | Can prompts or tools expose credentials? | Secret-scanning, vault policy, redaction tests |
| Monitoring | Can privileged AI actions be traced to a user, agent and decision? | Audit logs, correlation IDs, incident playbooks |
Evidence: Official guidance; Author analysis.
Relationship to existing Research entries
IAM for AI systems connects to:
- Zero Trust — identity, least privilege and telemetry are core AI control surfaces.
- RAG Security — retrieval must respect permissions and data classification.
- AI Security Architecture — architecture diagrams must show identities and trust boundaries.
- AI Threat Modeling — abuse cases should include impersonation, overprivileged agents and data leakage.
- Prompt Injection — injected instructions become more dangerous when the model has broad permissions.
- AI Governance — ownership and exception decisions need named accountability.
- Audit Evidence — access and action claims need retained records.
Governance relevance
AI IAM is governance-relevant because AI systems can combine human authority, service credentials, data retrieval and generated action. Without a clear identity model, it is difficult to prove who did what, why a tool was called or whether a data access decision was legitimate. Evidence: Author analysis; Implementation evidence required.
Useful governance outputs include AI identity inventory, access-control matrix, agent permission review, tool approval workflow, data-access tests and log-retention policy. Evidence: Author analysis.
Current limitations and follow-up research
This page is a methodology profile. Real assessment requires identity-provider details, data classification, tool/API scopes, agent runtime design, model-provider routing, logs and business-process approval rules.
Follow-up Research nodes should cover:
- Agent Security,
- AI Tool Authorization,
- Model Context Protocol security,
- AI audit logging,
- privilege management for autonomous workflows.