TL;DR: AI agents behave like software with human-like runtime judgment, and Aembit argues that workload identity alone cannot safely scope, attribute, or constrain that access because agent behaviour changes at runtime. The security issue is not deployment speed but access models built for deterministic workloads, where static credentials and fixed permission boundaries no longer hold.
NHIMG editorial — based on content published by Aembit: Squares and Rectangles: Why AI Agents Can’t Be Treated Like Regular Workloads
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should security teams govern AI agents that need access only for a single task?
A: Use just-in-time identity issuance tied to the task, not a standing account that remains valid after the work finishes.
Q: Why do AI agents complicate existing IAM and authorization models?
A: AI agents complicate IAM because they turn natural language into execution, which can cross systems faster than human review can intervene.
Q: What breaks when an AI agent is given a generic service credential?
A: A generic service credential breaks the link between task scope and access scope.
Practitioner guidance
- Define agent identity separately from user identity Create an identity model that records the agent as its own subject while linking it to the user session on whose behalf it acts.
- Issue runtime-scoped credentials for tasks Replace standing access with short-lived credentials that are minted for a specific task, resource, and policy decision, then expire when the task ends.
- Log the full authorization context Capture agent identity, user session, target resource, and policy outcome in the same event so investigators can answer who acted and why.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- How the blended identity model is applied at runtime across agent, user, and policy context
- The specific enforcement flow for issuing short-lived credentials to AI agents
- The visibility-versus-enforcement distinction that affects production rollout decisions
- The example integration pattern described for Microsoft Copilot Studio
👉 Read Aembit's analysis of why AI agents need blended identity →
AI agent identity: why workload identity alone falls short?
Explore further
AI agent identity is a new identity class, not a renamed workload. The article’s strongest point is that agent behaviour sits between workload determinism and human-session context, which is exactly why simple category mapping fails. If teams treat the agent as just another service account, they lose the runtime policy context that governs how the agent actually decides. The practitioner conclusion is to classify the actor first, then design the authorization model around that behaviour.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is why visibility alone is not enough.
A question worth separating out:
Q: How should security teams log AI agent actions for audit and compliance?
A: Security teams should log AI agent actions as identity events, not just application events. Each record should include the human initiator, agent identity, approved session scope, tool invocation details, and any downstream delegation. That structure lets investigators prove whether the action stayed within authorised boundaries and gives compliance teams a defensible record of accountability.
👉 Read our full editorial: AI agents need blended identity, not plain workload identity