They create a single policy that fits none of the real risk profiles. Builders need controls around training data and pipelines, users need limits on exposure and action, and agents need task-scoped permissions with tighter logging. Collapsing these into one policy usually produces either excess access or unusable restrictions.
Why This Matters for Security Teams
Builders, users, and agents look similar only at a distance. In practice, they generate different risk profiles, different blast radii, and different control failures. Builders need supply-chain, training-data, and pipeline protections. Users need exposure limits and constrained actions. Agents need task-scoped authority, runtime checks, and tight revocation. Treating them as one class usually produces policy that is either too broad to use or too weak to stop misuse.
That mismatch is already visible in real-world NHI exposure. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, a sign that broad access patterns are still the default rather than the exception. The problem becomes sharper in agentic environments, where autonomous tool use can turn a minor misgrant into lateral movement. Guidance from the OWASP Agentic AI Top 10 and NHI research such as the Ultimate Guide to NHIs both point to the same operational truth: identity type determines control type.
In practice, many security teams encounter the failure only after a builder pipeline, a user workflow, or an autonomous agent has already been granted the wrong kind of access.
How It Works in Practice
The right model starts by separating identity classes before policy is written. Builders are tied to repositories, CI/CD systems, model training jobs, and artifact signing. Their controls should focus on code integrity, secret handling, provenance, and change approval. Users are interactive humans or human-driven workflows, so the emphasis is on session risk, least privilege, and safe action limits. Agents are different: they operate toward goals, chain tools, and adapt at runtime, so they need workload identity, ephemeral secrets, and authorization that evaluates context at the moment of request.
That is why static, role-based IAM often fails for agents. A role can describe a person’s job, but it cannot reliably predict what an agent will attempt next. Current guidance suggests using policy-as-code, such as OPA or Cedar, to evaluate intent, tool, destination, and data sensitivity at runtime. For agentic systems, best practice is also shifting toward JIT credential issuance, short TTLs, and automatic revocation after task completion. The relevant identity primitive is workload identity, not a long-lived shared secret. Standards and implementation guidance from the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework reinforce that controls must be aligned to system behavior, not just named identities.
This is also where NHI lifecycle discipline matters. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into service accounts, which explains why mixed policies tend to hide privilege sprawl instead of correcting it. These controls tend to break down when agents are allowed to reach production tools through shared service accounts because the identity no longer maps cleanly to a single actor or purpose.
- Builders: protect training data, pipelines, signing keys, and deployment privileges.
- Users: constrain session scope, data exposure, and high-risk actions.
- Agents: issue per-task credentials, evaluate policy at runtime, and revoke on completion.
Common Variations and Edge Cases
Tighter separation often increases operational overhead, requiring organisations to balance control precision against engineering speed. That tradeoff is real, especially when teams run mixed workloads in one platform or move quickly between experimentation and production.
There is no universal standard for this yet, so guidance should be applied with judgment. For example, a builder may briefly behave like a user during debugging, and a user-facing assistant may trigger agent-like actions if it can invoke tools. Those boundary cases are where policy drift starts. The safer approach is to classify by behaviour and authority, then downgrade privileges whenever the role becomes ambiguous.
This is also where shared secrets and long-lived tokens become dangerous. When builders, users, and agents share the same credential patterns, revocation becomes slow and attribution becomes weak. NHIMG research shows that 71% of NHIs are not rotated within recommended time frames, which makes broad access especially risky. The AI LLM hijack breach and the Moltbook AI agent keys breach show how quickly identity confusion turns into exposure when keys outlive the task or the actor that should have used them.
In short, the failure is not just over-permissioning. It is collapsing three different operating models into one control model and then expecting the policy engine to infer intent that was never encoded.
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 | A-03 | Covers agent misuse when autonomous tools get broader access than intended. |
| CSA MAESTRO | M-02 | Addresses agentic workload identity and task-scoped privilege design. |
| NIST AI RMF | AI RMF requires governance that reflects different actors, uses, and risks. |
Separate builder, user, and agent governance paths and apply controls to each behavior class.
