Should AI governance be handled as a policy problem or an identity problem?

Policy sets intent, identity sets reach

AI governance becomes a policy problem only when the discussion stays at rules, approval paths, and acceptable use. It becomes an identity problem when an agent can authenticate, receive delegated authority, or call internal systems. At that point, the security question is no longer just “should it act?” but “what can it actually reach, under what identity, and with what privilege?”

That distinction matters because policy can describe limits, but it cannot enforce or prove access on its own. If an agent is handed standing credentials, excessive scopes, or a reusable token, the operational control point shifts to identity lifecycle, authorization, and credential governance.

An agent with no internal reach can often be governed like a policy-bound application. An agent with internal reach should be treated like an identity-bearing actor, because the access path determines the blast radius long before any policy review does.

Why the access path changes the governance model

Once an AI system can touch internal services, the relevant control set looks much closer to IAM, PAM, and lifecycle governance than to a pure policy handbook. The same agent may need registration, a named owner, scoped entitlements, expiration, revocation, and monitoring of which systems it can call. If those controls are missing, policy becomes advisory rather than enforceable.

This is why many teams separate “AI policy” from “agent identity governance.” The policy defines approved use cases, human oversight, and prohibited behavior, while identity design determines whether the agent can impersonate a user, use a service account, or act through tightly bounded delegation. For practitioners, that separation is useful only if the identity layer is designed first enough to prevent uncontrolled access by default.

That also means governance must cover both human-made and machine-made access paths. If an internal workflow, connector, or tool grants the agent broad access simply because it is part of the platform, the governance failure is structural, not rhetorical.

What practitioners should look for first

When deciding whether the issue is mainly policy or identity, start with the system’s access pattern, not the policy statement. If the agent can read, write, or trigger actions in internal systems, then identity evidence, scope boundaries, and revocation capability are the first things to verify. If it cannot reach anything sensitive, the immediate need is usually policy clarity, approval workflow, and human review thresholds.

For broader identity governance context, the distinction between policy and access control is captured well in NHIMG’s IAM and IGA Basics, which explains how authorization, provisioning, and access review fit together. Where agents have real operational reach, the lifecycle issues in NHI Lifecycle Management Guide become directly relevant because standing access, rotation, and offboarding determine whether policy can be enforced over time.

For AI-specific governance, the practical question is whether the agent is governed as an approved workflow or as an autonomous actor. NHIMG’s Agentic AI Security Policy Template is useful when you need a policy structure, but it only works when identity and access constraints are already defined clearly enough to make the policy enforceable.

Risk and Threat Considerations

Policy-only governance fails when an agent can obtain or reuse credentials that outlive the approval that created them. In that case, the real risk is privilege drift: the policy says one thing, but the access path continues to enable actions after the original context has changed. Threat actors also benefit when delegated access is broad, because a compromised agent identity can be used to move laterally or act at machine speed.

Failure mechanism: standing credentials, overbroad scopes, or poorly governed delegation let the agent keep reaching internal systems after the policy decision has aged out, been misread, or never been wired into enforcement.

Impact: unauthorized data access, unapproved actions, harder incident containment, and a larger blast radius if the agent, connector, or token is abused.

Practitioner Guidance

What to prioritise: classify every AI system by whether it merely recommends actions or can actually execute them. The latter category needs identity ownership, credential inventory, scope review, and revocation paths before it needs a broader policy debate.

What to verify: confirm which identity the agent uses, whether it is shared or unique, whether scopes are least privilege, and whether access can be removed without breaking unrelated systems. If you cannot revoke the access cleanly, the governance model is incomplete.

Decision rule: if the agent can reach internal systems, treat it as an identity-bearing actor first and a policy subject second. If it only influences human decisions, policy and oversight may be the primary control layer.

Practitioner takeaway: policy defines acceptable behavior, but identity determines whether that behavior is even possible, so effective AI governance must be enforceable at the access layer rather than assumed at the policy layer.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?
• Why is NHI governance critical in the age of AI attacks?