Should organisations rework IAM when AI systems begin to act on data?

Why This Matters for Security Teams

When AI systems can read, transform, or trigger actions on data, traditional IAM assumptions start to fail. A human user can be trained, warned, and audited in a familiar way, but an AI workflow may move across systems at machine speed, reuse delegated tokens, and operate beyond the original intent of the access grant. That creates a governance problem as much as an access-control problem.

Security teams often discover that “allowed” does not mean “safe” once an AI agent begins to act on behalf of a person or process. The key issue is not whether the identity is valid, but whether the privilege is still appropriate for autonomous use, whether the action can be traced to a clear owner, and whether the workflow has guardrails for data exposure and destructive actions. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant here because accountability, least privilege, and auditability are still the baseline, even when the actor is software.

In practice, many security teams encounter this only after an AI workflow has already overreached its original permissions, rather than through intentional design.

How It Works in Practice

Reworking IAM for AI-driven actions usually starts with separating human identity from delegated machine action. That means identifying where an AI system is merely assisting a user and where it is actually executing steps with authority. In the second case, the entitlement model needs to reflect runtime context, not just a static role. Best practice is to treat AI action as a controlled delegation, with explicit approval boundaries, scoped credentials, and logging that links each action back to a business owner.

Operationally, teams should consider four questions:

• What data can the AI read, summarise, or pass into other systems?
• What actions can it take without step-up approval?
• What secrets, tokens, or service accounts enable those actions?
• How will reviewers prove who authorised the delegation and for how long?

This is where NHI governance becomes relevant. If an AI agent uses secrets or service identities, those credentials should be managed like any other non-human identity, with expiry, rotation, scoping, and ownership. Current guidance suggests that AI-connected access should be reviewed under the same least-privilege and separation-of-duties principles used for privileged access. Zero standing privilege, just-in-time elevation, and workflow approvals are particularly valuable when an agent can initiate changes or move sensitive data.

Auditability matters just as much as prevention. Logs should capture the originating user, the AI system version, the prompt or policy decision that triggered the action where feasible, and the downstream resource touched. Where an organisation uses retrieval-augmented generation or tool-using agents, the trust boundary expands, so content provenance and output validation become essential.

These controls tend to break down in highly dynamic environments where AI agents are spawned ad hoc and service identities are reused across many tools because attribution and revocation become unreliable.

Common Variations and Edge Cases

Tighter delegation controls often increase operational overhead, requiring organisations to balance AI agility against auditability and risk containment.

There is no universal standard for this yet, especially for agentic systems that blend recommendation, retrieval, and execution. Some organisations can keep AI under human-in-the-loop approval for every sensitive action; others need semi-autonomous workflows because the business case depends on speed. The right answer depends on the sensitivity of the data, the blast radius of the action, and the maturity of the control environment.

Edge cases appear when AI touches regulated data, privileged admin functions, or cross-domain integrations. In those cases, IAM is not just about login control. It becomes part of a broader assurance model that includes data classification, secrets governance, approval workflows, and incident response. If the AI is connected to customer records, financial systems, or production infrastructure, stronger monitoring and narrower scope are usually justified.

For organisations handling high-risk decisions, current guidance suggests treating AI action rights as time-bound, purpose-bound permissions rather than durable access grants. That approach is especially important when an AI system can act independently of the person who originally approved it, because ownership can become unclear once the workflow is handed off.

Related resources from NHI Mgmt Group

• How should security teams govern AI assistants that can act inside IAM systems?
• How should organisations govern access to data used by AI systems?
• How should healthcare organisations govern AI when data comes from many systems?
• What should organisations do before an AI assistant can act on real systems?