Notifications
Clear all
Topic starter
18/08/2026 2:13 pm
TL;DR: API gateways and directories can observe AI agents but cannot govern what they do at execution time, especially when agents share credentials or touch regulated systems, according to Stacklok. Identity-first control moves identity into the workload path so every model call, tool call, and spend event resolves to a named agent, which changes accountability and enforcement.
NHIMG editorial — based on content published by Stacklok: Observers or governor? Why your AI control plane needs identity-first controls
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
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.
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.
Q: What breaks when AI agent identity is attached only at the directory layer?
A: You get authentication without behavioural control.
Practitioner guidance
- 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.
- Eliminate shared service accounts for high-risk agents Assign distinct identities to agents that can touch regulated data, production systems, or spend-bearing workflows.
- 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.
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
👉 Read Stacklok's analysis of identity-first controls for AI agent governance →
AI agent identity-first controls: are your current guardrails enough?
Explore further
18/08/2026 3:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent identity-first controls define who can govern actions
