Who should approve creation and permission grants for a new agent identity?

Why This Matters for Security Teams

Approval design is not just a workflow question. For a new agent identity, the approver determines whether the identity is governed as a bounded workload or as a convenience shortcut that can later expand into broad access. In NHI programs, the risky pattern is letting one person create the identity and approve every permission attached to it, because that collapses segregation of duties and hides privilege creep. NHIMG notes that 97% of NHIs carry excessive privileges, which makes approval separation a practical control rather than an administrative preference.

That separation matters even more for agentic systems, where the identity may be created for one task and then reused across tools, data sets, and execution paths that were not obvious at approval time. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward stronger governance at the point of capability assignment, not just identity creation. In practice, many security teams encounter privilege expansion only after an agent has already inherited too much access through a well-meaning request path.

How It Works in Practice

The cleanest pattern is to split responsibilities by decision type. Identity governance and the owning application team should approve whether the agent identity should exist at all, while resource owners or data owners should approve each permission grant that the agent needs. That means one workflow for object creation and a separate workflow for access entitlements. The first decision answers, “Should this agent have a distinct identity?” The second answers, “Should this identity be allowed to do this specific action in this specific environment?”

This is consistent with the control direction in OWASP Non-Human Identity Top 10 and with NHIMG’s guidance in the Ultimate Guide to NHIs. In operational terms, the approval record should capture:

• the business purpose of the agent
• the owning team and accountable approver
• the exact services, datasets, and tools the agent may touch
• the duration of the grant and the review date
• whether the permission is standing or just-in-time

For agentic workloads, the better practice is to issue the identity with the minimum viable baseline and then grant short-lived permissions only when a task requires them. That aligns with intent-aware authorisation and reduces the chance that a valid identity becomes a durable privilege container. Where possible, approval should be attached to a policy decision path, not a static ticket, so the access request can be evaluated in context by policy-as-code rules rather than by memory or convenience. These controls tend to break down when the agent is embedded in CI/CD or event-driven pipelines because approvals get bypassed in favor of automation speed.

Common Variations and Edge Cases

Tighter approval separation often increases friction, so organisations need to balance faster delivery against stronger privilege control. That tradeoff becomes visible when platform teams create many short-lived agents for testing, data enrichment, or multi-step workflows. Current guidance suggests these cases should not get blanket approvals just because they are ephemeral; best practice is evolving toward scoped, time-bound permission grants with explicit revocation.

One common exception is fully automated service-to-service identities, where no human can approve each runtime grant. In those environments, approval should move upstream into policy design, workload attestation, and environment controls. Another edge case is delegated administration in large platforms: a platform owner may approve the identity object, but domain owners still need to approve access to sensitive systems. That split is especially important when agent behavior can chain tools and expand reach across services.

NHIMG research shows why this matters: the 52 NHI Breaches Analysis and the Top 10 NHI Issues both reinforce that weak ownership and excessive standing access are recurring failure modes. A practical rule is simple: creation approval belongs to governance plus application ownership, while permission approval belongs to the owner of the resource being protected. Anything less usually turns into approval theater, especially once the identity starts moving between systems and teams.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?
• When does secret exposure become a broader identity risk?
• Why is single-provider AI agent governance not enough for enterprise security?