AI agent identity-first controls define who can govern actions

At a glance

What this is: This is an analysis of why observation tools can see AI agent activity but cannot enforce identity at execution, and why workload-attached identity changes governance.

Why it matters: It matters because IAM, IGA, PAM, and security architects need controls that attribute, constrain, and stop agent actions in real time, not just log them after the fact.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Stacklok's analysis of identity-first controls for AI agent governance

Context

AI agent identity-first controls mean the agent's identity is enforced where the work happens, not only where the login begins. The governance gap is simple: observation tools can confirm that an action occurred, but they cannot reliably attribute, constrain, or stop the action once the agent is already inside the execution path.

That gap becomes more serious when organisations rely on shared service accounts, perimeter gateways, and directory-level authentication to govern agent behaviour. Those tools still matter, but they were designed to observe access events and issue credentials, not to decide every model call and tool call in flight.

The article's core claim is that identity must travel with the workload if teams want per-agent accountability, execution-time enforcement, and cost attribution. That is a typical problem in early agent rollouts, but it becomes a structural control failure as agent fleets grow and start touching sensitive or regulated systems.

Key questions

Q: How should security teams govern AI agents that use service accounts and MCP tools?

A: Start with ownership, then add runtime attribution and containment. Security teams should know which human deployed the agent, which identity the agent uses, what tools it can invoke, and when to revoke access. If the agent can chain tool calls or spawn sub-agents, governance must cover those paths as well, not just the initial login.

Q: Why do API gateways fall short for autonomous agent governance?

A: API gateways fall short because they treat each request as independent and do not model conversation flow, delegation, or the business meaning of a tool call. Autonomous agents need controls that understand sequence and context, not just authentication and routing. Without that, the gateway cannot tell whether a call is still within scope.

Q: What breaks when AI agent identity is attached only at the directory layer?

A: You get authentication without behavioural control. The directory can confirm that an agent is valid, but it cannot decide each downstream model call or tool call once the session is underway. That creates a gap between access establishment and action governance, which is exactly where high-risk agent behaviour needs control.

Q: Who is accountable when an AI agent makes an unauthorised change?

A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.

Technical breakdown

Why API gateways can observe agents but not govern execution

An API gateway sits on the traffic path and inspects requests as they pass. That gives it visibility into calls, rate limits, and policy matches, but only at the perimeter. Once the request is allowed through, the gateway is no longer in the decision loop for what the agent does next. This makes it useful for observation and coarse control, but weak for action-level governance. In agentic environments, the difference matters because a single authenticated session can hide multiple downstream tool calls, each with different risk. The core limitation is temporal: the gateway sees access, not the full sequence of decisions.

Practical implication: Treat gateways as monitoring and coarse enforcement layers, not as the control point for high-risk AI agent actions.

How workload-attached identity changes model call and tool call control

Identity-first governance attaches the agent's identity to the workload itself, so each model call and tool call resolves to a named principal. In the article's model, the control plane runs the workload inside a pod it creates, which means identity is enforced in the execution path rather than inferred from side-band logs. Short-lived tokens reduce replay risk, and the directory becomes a provisioning and authentication source rather than the final governor of behaviour. The important architectural change is that identity is no longer a front-door check. It becomes a runtime control.

Practical implication: Align agent identity with workload identity so execution-time policy can decide each action instead of only recording it.

Why shared service accounts break attribution and spend governance

Shared service accounts collapse multiple agents into one principal, which removes the ability to tell which agent performed a specific action. That creates an accountability problem for security, finance, and operations at the same time. A gateway can meter the account, but not the workflow or team behind each action. When agents share credentials, the organisation loses the ability to correlate behaviour with purpose, cost, and blast radius. This is a governance failure, not just a logging problem, because the identity boundary has been flattened before the action occurs.

Practical implication: Separate agent identities before scale forces shared credentials into operational practice.

NHI Mgmt Group analysis

Identity-first governance is the right control model for AI agents because perimeter observation cannot enforce action-level intent. API gateways and directories still have a role, but they operate outside the point where agent behaviour becomes consequential. Once an agent can chain model calls and tool calls, the relevant control question is no longer whether it authenticated, but whether each action was authorised at execution. That shifts governance from observability to enforcement, which is a different discipline.

Shared service accounts create identity collapse for agent fleets. When multiple agents act under one principal, attribution, auditability, and cost allocation all degrade at once. The organisation can see that something happened, but not which agent did it, for whom, or at what spend level. That is a named governance concept worth carrying forward: agent identity collapse means the loss of distinct, enforceable accountability when machine actors share a credential boundary. Practitioners should treat shared-agent identity as a structural defect, not a convenience.

Execution-time identity matters more as agent risk moves from read-only tasks to regulated or financial actions. A workload that can read data is easier to observe; a workload that can change records, move money, or trigger downstream systems needs enforcement in the path. This is where IAM, PAM, and IGA principles converge for non-human actors. The control failure is not lack of visibility, but lack of decisional authority at the moment of action.

Directory-centric governance remains necessary, but it is no longer sufficient for autonomous-looking agent behaviour. OIDC, SCIM, and the enterprise IdP can still provision and authenticate the actor, yet they do not resolve what happens inside the session. The field should stop treating directory success as equivalent to behavioural control. Practitioners need to distinguish access establishment from access governance, or they will continue to certify the login while missing the action.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows how often policy assumptions break at the implementation layer.
• The governance pattern in this article aligns with the Ultimate Guide to NHIs, especially where lifecycle control and workload identity need to converge.

What this signals

Agent identity collapse: when multiple AI agents share one account, the organisation loses attribution, policy precision, and spend visibility in the same move. That makes workload identity a governance requirement, not an architectural preference, and it is one reason identity programmes need to distinguish access provisioning from execution control.

The practical signal for IAM teams is that agent rollout will force a reclassification of control points. If your current model depends on perimeter inspection, directory authentication, and post-event logging, it will remain informative but not authoritative for high-risk agent actions. That distinction is now central to agent governance and should be reflected in architecture reviews, access recertification, and PAM design.

Identity-first execution also changes how teams should think about lifecycle management. Once agents become named workload principals, offboarding, revocation, and ownership transfer need to be part of the same operational flow that provisions them, which is why lifecycle discipline matters as much for machine actors as it does for humans.

For practitioners

• Map the control boundary for each agent workflow Document where the directory authenticates the agent, where the workload executes, and where action-level policy is actually enforced. If those points are not the same, you have an observation layer, not an execution governor.
• Eliminate shared service accounts for high-risk agents Assign distinct identities to agents that can touch regulated data, production systems, or spend-bearing workflows. Shared credentials should be treated as temporary exceptions with explicit expiry and owner sign-off.
• Separate auditability from enforceability in your architecture review Check whether your current tooling can only log that an action occurred, or can also deny it before completion. For high-stakes use cases, only the second capability closes the governance gap.
• Tie spend and ownership to named agent identities Require each agent to resolve to a team and workflow so cost reporting, access review, and incident review all use the same identity record. That makes accountability operational instead of forensic.

Key takeaways

• AI agent governance fails when teams confuse observation with enforcement, because logging an action is not the same as controlling it.
• Shared service accounts collapse attribution for machine actors, which weakens access review, spend accountability, and incident investigation at the same time.
• The control model is shifting toward workload-attached identity, where every model call and tool call must resolve to a named principal.

Key terms

• Identity-first governance: A governance model that treats non-human and autonomous systems as identities with ownership, scope, and accountability. It requires the same discipline used for human and machine identities, but adds tighter runtime control because the actor may change behaviour during execution.
• Agent identity collapse: The loss of distinct, enforceable accountability when multiple AI agents share one credential or principal. It weakens attribution, access control, and cost allocation because the organisation can only see the account, not the individual agent behaviour behind it.
• Execution-time control: A policy or guardrail that blocks or restricts a tool while it is running, before it can read secrets, execute commands, or exfiltrate data. For developer environments, execution-time control is the difference between observing a malicious artifact and stopping it from doing harm.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• How the runtime pod model enforces identity inside the execution path rather than beside it
• How OIDC, SCIM, Okta, and Entra fit into the agent lifecycle model described by the vendor
• How short-lived tokens are used to avoid long-lived credential replay in the product design
• How the AI gateway and MCP gateway differ from the control plane that actually runs the workload

👉 Stacklok's full post covers the runtime model, token handling, and agent lifecycle flow in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.