Because they assume a human operator will interpret context and bridge every step between intent and execution. Agents and automation do not work that way. They need identity controls that are discoverable, composable, and auditable inside the workflow itself, not hidden behind a separate administrative screen.
Why This Matters for Security Teams
Console-based IAM works when a human can pause, interpret, and approve each access request. Agentic enterprise workflows do not pause for that kind of mediation. Agents chain tools, follow goals, and change execution paths at runtime, which means permissions hidden in an admin console are often invisible at the moment they are needed. That gap turns identity governance into a workflow failure, not just an access-control issue.
Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward runtime evaluation, accountability, and constrained autonomy rather than static approval screens. NHIMG research shows why this matters operationally: in the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope.
For security teams, the problem is not simply whether an agent has access, but whether that access is discoverable, time-bound, and auditable inside the path of execution. In practice, many security teams discover these gaps only after an agent has already touched sensitive data or attempted an unauthorised action, rather than through intentional design.
How It Works in Practice
Agentic workflows need identity controls that travel with the workload. The common pattern is to treat the agent as a workload identity, then issue narrowly scoped, short-lived access only when a task is invoked. That is very different from assigning a standing role in a console and expecting an operator to remember when it should or should not be used. Best practice is evolving toward context-aware authorisation, where policy is evaluated at request time based on the task, data sensitivity, tool being called, and current risk signal.
In practical terms, teams usually combine several mechanisms:
- Workload identity for the agent itself, such as SPIFFE-based identities or OIDC-backed tokens, so the system can prove what the agent is.
- Just-in-time credentials with very short TTLs, so secrets exist only for the duration of a task.
- Policy-as-code using engines such as OPA or Cedar, so access decisions happen in-line instead of in a separate admin console.
- Tool-level constraints that limit which APIs, repos, or data zones the agent can reach during that task.
The operational benefit is that the workflow can verify both intent and authority in real time, rather than forcing a human to bridge the gap between execution and approval. NHIMG has highlighted the maturity gap here in the 2024 Non-Human Identity Security Report, which found that 88.5% of organisations say non-human IAM lags human IAM. That gap becomes especially visible when agents need ephemeral access across hybrid or multi-cloud systems, where console-based review simply cannot keep pace.
These controls tend to break down when the workflow depends on nested tool calls across multiple platforms because policy context fragments before the final action is executed.
Common Variations and Edge Cases
Tighter runtime control often increases integration overhead, so organisations have to balance autonomy against operational friction. That tradeoff is real: agents that are too constrained become brittle, while agents that are too open become difficult to govern. There is no universal standard for this yet, especially for multi-agent systems where one agent delegates to another and the effective blast radius is harder to predict.
One common edge case is legacy enterprise software that only exposes coarse console permissions and lacks APIs for runtime evaluation. In those environments, teams often start with wrapper services, brokered access, or step-up approval for high-risk actions, but those are compensating controls rather than ideal agent-native governance. Another edge case is shared secrets in long-lived automation accounts. NHIMG’s research note on the Moltbook AI agent keys breach illustrates why static keys are especially risky when agents can copy, reuse, or leak credentials outside the original workflow.
The best-practice direction, supported by the CSA MAESTRO agentic AI threat modeling framework, is to design for least privilege, ephemeral access, and explicit task boundaries from the start. Console IAM can still support governance review, but it should not be the control plane that decides live agent behaviour.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic workflows need runtime access controls, not static console permissions. |
| CSA MAESTRO | MAESTRO models agentic threat paths and control points across autonomous workflows. | |
| NIST AI RMF | GOVERN | AI RMF GOVERN stresses accountability for autonomous systems and their actions. |
Assign ownership, policy, and review responsibilities for agent decisions before deployment.
Related resources from NHI Mgmt Group
- Why do agentic debugging workflows create new IAM risk even when they stay inside CI?
- What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
- Why do RBAC-only models struggle in enterprise retrieval workflows?
- Why do role-based provisioning models matter in enterprise IAM?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
