How should security teams evaluate agentic AI and digital employees in identity governance programs?

Security teams should treat agentic AI as a governed identity class, not as a generic automation tool. Start by defining what the agent can access, which tasks it may perform, and when human approval is required. Apply least privilege, logging, periodic review, and clear ownership so autonomous actions remain traceable and reversible within existing IAM and NHI controls.

Why This Matters for Security Teams

Agentic AI and digital employees change identity governance because they do not behave like static service accounts or traditional users. They can chain tools, request new permissions mid-task, and act across systems faster than human review cycles can react. That makes the identity question operational, not theoretical: who owns the agent, what can it do, and how is each action bounded in time and context?

Current guidance suggests treating these systems as a governed identity class with explicit lifecycle controls, not as a generic automation layer. Security teams should evaluate whether the agent has workload identity, whether secrets are short-lived, and whether approvals are tied to the task rather than the account. OWASP’s OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework both reinforce the need for runtime governance, traceability, and human accountability.

NHIMG research shows why that matters in practice: only 1.5 out of 10 organisations are highly confident in securing NHIs, and lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations in The State of Non-Human Identity Security. In practice, many security teams encounter agentic abuse only after the agent has already used valid access to move faster than their review process could contain it.

How It Works in Practice

The most reliable evaluation approach starts by classifying the agent as an identity-bearing workload with a defined purpose, owner, and expiry model. That means assigning a workload identity, not just a username or shared API key. In practice, teams often combine SPIFFE-style workload identity, OIDC-issued tokens, and policy-as-code so the agent proves what it is at request time and receives only the access needed for the current task.

For digital employees, security teams should test four control layers:

• Purpose scoping: what business task the agent is allowed to perform.

• Runtime authorisation: whether access is granted based on the current context, not a prebuilt role alone.

• JIT credentialing: whether credentials are issued per task and revoked automatically on completion.

• Auditability: whether every tool call, data access, and escalation is logged with an owner and timestamp.

This is where static IAM fails. An agent may appear low risk at onboarding, then later chain prompts, tools, and data sources in ways that were never anticipated. The better control pattern is intent-based or context-aware authorisation, where policy evaluates the requested action, the target system, the sensitivity of the data, and the state of the task. That direction is consistent with the control thinking in CSA MAESTRO agentic AI threat modeling framework and NHIMG’s OWASP Agentic Applications Top 10, which both emphasise runtime risk rather than one-time provisioning.

Security teams should also review whether secrets are durable or ephemeral. Long-lived tokens are hard to justify for autonomous systems because the blast radius expands the longer a credential remains valid. A more mature model uses short TTLs, automatic revocation, and step-up approval for high-impact actions such as finance, production changes, or data export. These controls tend to break down in highly distributed multi-agent pipelines because each hop introduces another trust boundary and another place where identity context can be lost.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance speed of execution against review depth and integration complexity. That tradeoff becomes visible when the “digital employee” is expected to work across many systems, since every connector, plugin, and delegated token introduces a new governance decision.

There is no universal standard for this yet, so current guidance suggests different treatment by use case. A customer-support agent that drafts responses may only need read-only access plus approval before sending. A code-writing agent may need repository access, but with branch-level restrictions and mandatory human merge control. A procurement or finance agent may require stronger separation, dual approval, and time-bounded access because a single mistake can create irreversible business impact.

Security teams should be cautious with delegated human identities, shared service principals, and overbroad roles that masquerade as convenience. Those patterns can work in narrow automation, but they are weak for autonomous behaviour because they do not express intent well enough. If the agent can discover new paths at runtime, the governance model must be able to stop lateral movement, not just authenticate the first login. NHIMG’s Ultimate Guide to NHIs and Top 10 NHI Issues are useful references for mapping these controls back to established NHI governance patterns.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• How should IAM teams evaluate agentic AI for identity operations in enterprise environments?
• How should security teams evaluate agentic AI governance platforms for enterprise scale?
• How should security teams evaluate third-party SaaS app risk in identity governance programs?