Notifications
Clear all
Topic starter
06/06/2026 2:15 am
TL;DR: AI agents are beginning to invoke APIs, access sensitive systems, and make runtime decisions on behalf of humans, which breaks security models built around a one-time login and static trust, according to SecurEnds. The core issue is that access review and traditional authorization assume stable, reviewable privilege, while AI execution is continuous and context dependent.
NHIMG editorial — what this means for AI and NHI governance
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of users?
A: Treat each agent as an accountable operational identity with a named owner, bounded entitlements, and runtime policy enforcement.
Q: Why do static IAM controls break down for AI agent execution?
A: Static IAM assumes privileges can be defined and reviewed in advance, but AI agents make decisions at runtime and can change their execution path during the session.
Q: What do security teams get wrong about AI agent visibility?
A: They often stop at API logs or model outputs, which misses the identity chain behind the action.
Practitioner guidance
- Assign explicit ownership for every AI agent Record which human or team owns the agent, what authority was delegated, and which systems the agent may touch.
- Move high-risk AI actions to runtime policy decisions Require allow, challenge, or deny decisions at the point of action for sensitive systems, rather than relying on the original login or session grant.
- Link agent telemetry to identity and route context Correlate agent-to-tool events, MCP routing paths, and the originating human identity so investigations can reconstruct who caused what, through which path, and under which policy decision.
What's in the full announcement
SecurEnds' full article covers the operational detail this post intentionally leaves for the source:
- The concrete Nexus AI Security control flow for allow, challenge, and deny decisions at runtime
- The APIDynamics visibility model for tying agent actions to MCP routing and execution context
- The IGA ownership model for mapping AI identities to human delegators and entitlement scope
- The article's end-to-end architecture for connecting identity, visibility, and control across AI execution
👉 Read SecurEnds' analysis of AI agent execution governance and runtime control →
AI agent execution and identity governance: are controls keeping up?
Explore further
06/06/2026 3:49 am
AI execution creates an identity governance problem, not just an AI monitoring problem. The article correctly shifts the discussion from content generation to action execution, which is where identity risk becomes operational. Once an agent can invoke APIs and orchestrate work on behalf of a human, the governing question becomes who is accountable for the action path, not merely who approved the request. Practitioners should treat this as runtime identity control, not model oversight.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, showing how quickly governance gaps become durable exposure.
A question worth separating out:
Q: How do organisations decide whether an AI agent should be allowed to act autonomously?
A: Autonomy should be granted only when the business process can tolerate runtime action, the owner is clear, the policy engine can make immediate decisions, and the activity is fully attributable. If any of those are missing, the safer model is constrained delegation with challenge or denial for sensitive steps.
👉 Read our full editorial: AI execution needs runtime identity governance, not static trust
