How should organisations govern AI agents alongside human identity and device access?

Why This Matters for Security Teams

AI agents should not be folded into human IAM or device access as if they were just another user or endpoint. Their access is programmatic, goal-driven, and often delegated across tools, APIs, and data stores in ways that do not match interactive sign-in assumptions. Current guidance from the OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework points toward actor-specific controls because autonomous systems can chain actions faster than approval workflows can respond.

That matters most when an agent inherits broad entitlements from a human operator or service account. The risk is not only over-permissioned access, but also hidden privilege amplification as the agent moves between tools, secrets, and devices. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the pattern that becomes dangerous when autonomous workflows are added on top. In practice, many security teams encounter agent overreach only after a delegated workflow has already touched systems it was never meant to reach, rather than through intentional access design.

How It Works in Practice

The operational model is to govern AI agents as a separate identity class with their own lifecycle, entitlement boundaries, and runtime policy checks. That usually means the agent authenticates as a workload identity, not as a person, and receives permissions only when a task requires them. Implementation patterns increasingly use short-lived credentials, token exchange, and request-time policy evaluation rather than standing entitlements. Standards bodies are still converging on the details, but the direction is clear: use context-aware authorization for the action, not static approval for the actor.

A practical control stack often includes:

• Workload identity for the agent, such as SPIFFE-style identity or OIDC-backed tokens, to prove what the agent is.
• JIT credential issuance with narrow TTLs so access expires when the task ends.
• Policy-as-code, such as OPA or Cedar, to evaluate intent, data sensitivity, and tool scope at request time.
• Separate logging and audit trails that show which model, prompt, tool call, and secret were involved.
• Explicit delegation rules that define which human-approved actions an agent may perform and which remain human-only.

This approach aligns with the governance direction in CSA MAESTRO agentic AI threat modeling framework and the OWASP Non-Human Identity Top 10, which both emphasize lifecycle control, secret exposure, and least privilege for machine actors. NHIMG research on the AI LLM hijack breach also illustrates how quickly exposed NHI credentials can be abused once an attacker finds a path into an agentic workflow. These controls tend to break down in legacy environments where one shared service account, one secrets vault, and one broad network zone are reused for every automation.

Common Variations and Edge Cases

Tighter agent governance often increases engineering overhead, so organisations have to balance blast-radius reduction against workflow friction. That tradeoff is real, especially where agents support operational tasks that need low latency or cross-domain access. Best practice is evolving, and there is no universal standard for how much autonomy should be allowed without a human approval step.

Edge cases usually appear in three places. First, long-running agents may need refreshed context and re-authorization mid-task, which makes short TTLs necessary but operationally awkward. Second, multi-agent systems can hand off work between identities, so one agent’s safe scope can become another agent’s escalation path unless delegation is explicitly bounded. Third, device-centric controls alone do not solve the problem when the risky actor is a cloud workload, not an employee laptop.

The safest pattern is to separate identity, device, and agent governance while still correlating them in monitoring and incident response. That means a human user may approve the mission, a device may satisfy posture checks, and the agent may still receive only a constrained workload identity for a single task. Where organisations try to merge those layers into one control plane, they usually end up granting too much trust to the agent or too much friction to the human. That gap is where hidden privilege growth and secret reuse tend to accumulate. The emerging consensus in NIST AI Risk Management Framework guidance is to manage these risks explicitly rather than assuming existing IAM review cycles will catch them.

Related resources from NHI Mgmt Group

• How should organisations govern AI agents that need database access?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents increase non-human identity risk in existing IAM programmes?