AI execution needs runtime identity governance, not static trust

At a glance

What this is: This is an independent analysis of AI agent execution security and the finding that static human-centric access models do not fit runtime AI behaviour.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern entities that act continuously at machine speed, with implications for ownership, visibility, and real-time authorisation across human, NHI, and autonomous workflows.

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%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read SecurEnds' analysis of AI agent execution governance and runtime control

Context

AI agent execution changes the security problem from one-time access to runtime action. In this model, a human delegates intent, but the agent invokes tools, APIs, and orchestration paths on its own during the session, which means traditional identity checks no longer describe the full risk picture.

The primary governance gap is not just who logged in, but who can act, when, and through which delegated path. For identity teams, this is a shift in control design across NHI, agentic AI, and existing lifecycle governance, because ownership and observability now have to follow execution rather than login alone.

Key questions

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. The key is not the human login that started the session, but the agent’s actual ability to invoke tools, access APIs, and complete work. If the agent can act independently, governance has to follow the action path, not the request path.

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. That means a valid login can become broad standing trust for later actions. The control model has to move from entitlement grant to continuous authorization at the point of action.

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. Visibility only becomes useful when it links the agent, the human delegator, the route taken through orchestration, and the policy decision applied. Without that context, investigations and access reviews cannot explain why the action was allowed.

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.

How it works in practice

Human intent to agent execution: where the trust model changes

The article describes a delegated execution chain in which a human supplies intent and an AI agent performs actions through MCP, orchestration, tools, and APIs. That is materially different from a user session, because authorization is no longer a single decision at login. The practical risk is that the security boundary moves from the person to the operating identity, but most enterprise controls still treat the human as the meaningful principal. Once the agent can choose actions at runtime, the system needs identity context attached to every call, not just to the initial session.

Practical implication: map every AI agent to an accountable owner and a policy boundary before allowing tool access.

Runtime authorisation versus static roles in AI agent security

Static RBAC-style access assumes privileges can be granted, reviewed, and understood in advance. The article argues for continuous authorization because AI agents do not pause for human review and their execution paths can shift within a session. In identity terms, this is closer to a runtime policy engine than a conventional access grant. The core mechanism is evaluating the current agent, current tool, current context, and current risk signal at the point of action. Without that, a valid login can become a standing permission structure for whatever the agent decides to do next.

Practical implication: move sensitive AI actions to point-in-time decisioning rather than relying on initial authentication.

Visibility tied to identity and execution context

Raw API telemetry is not enough when AI systems are the actor. The article’s visibility layer depends on linking agent-to-tool calls, MCP routing, first-time access, and abnormal execution back to the specific identity chain. That is what turns logs into governance evidence. In practice, this matters because incident response, audit, and access review all fail if they cannot answer which agent acted, which human delegated authority, and whether the route or action was expected. Identity without execution context produces blind spots; execution without identity context produces accountability gaps.

Practical implication: instrument AI execution logs so every action is attributable to an agent, owner, route, and policy decision.

NHI Mgmt Group analysis

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.

Access review processes assume access is stable long enough to be reviewed, but agentic execution breaks that premise. That assumption was designed for identities whose privileges persist across observable windows. It fails when the actor makes runtime decisions, selects tools dynamically, and completes actions before a traditional review cycle can even observe the behaviour. The implication is that certification alone cannot describe or constrain agent behaviour.

Identity, visibility, and control now have to be joined at the same point of action. The article’s three-layer model aligns with how non-human execution must be governed in practice, because visibility without enforcement is just telemetry and enforcement without ownership is unaccountable automation. The named concept here is runtime execution governance: control that follows the action, not the login. Practitioners should align governance boundaries to execution events.

AI agents should be governed as operational identities, not as temporary workflow helpers. That framing matters because ownership, entitlement scope, and lifecycle state all become audit objects once the agent can act independently within a business process. If the identity model stops at the human initiator, the enterprise loses the ability to answer basic questions about privilege provenance and behavioural drift. Practitioners should extend lifecycle governance to the delegated actor, not just the delegating person.

Continuous authorization is becoming the default control expectation for high-risk AI actions. The article’s allow, challenge, deny model shows where the market is heading: toward runtime decisions based on identity context, routing context, and behavioural signals. That direction validates Zero Trust thinking, but it also complicates older IAM assumptions about fixed entitlements and durable sessions. Practitioners should expect policy engines to sit closer to execution than to login.

From our research:

• 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.
• That visibility problem is why Top 10 NHI Issues remains a useful forward look at the controls most teams still miss.

What this signals

Runtime execution governance is becoming the operating model for AI-driven identity programmes. Teams that still centre their controls on login and entitlement review will miss the moment where the real decision happens, which is inside the session when the agent calls the tool, routes the request, and commits the action.

The immediate programme signal is that AI agent behaviour must be governed like other high-risk non-human identities, with owner mapping, policy enforcement, and auditable execution paths. With 80% of organisations already reporting out-of-scope agent behaviour, per the AI Agents: The New Attack Surface report, the gap is no longer theoretical.

For identity teams, the next step is to tie agent lifecycle controls to runtime evidence. That means access reviews should reflect actual execution, not only provisioned entitlement, and it means the identity fabric must be able to answer which agent did what, for whom, and under which policy decision.

For practitioners

• 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. If ownership cannot be named, the agent should not be granted tool or API access.
• 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. Use contextual signals such as first-time access, unusual routing, and entitlement mismatch.
• 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.
• Extend lifecycle governance to delegated AI identities Include onboarding, entitlement review, and offboarding for AI agents in the same governance calendar used for other non-human identities. Revoke access when the business purpose or owner changes, not only when the human relationship changes.

Key takeaways

• AI agents change the identity problem from static access to runtime execution, which means traditional login-centric controls no longer describe the real risk.
• The evidence already points to scale, with agent behaviour beyond intended scope showing up in most organisations that have deployed them.
• The control that matters most is point-of-action authorisation tied to identity, ownership, and execution context, not another layer of passive monitoring.

Key terms

• Runtime Execution Governance: Runtime execution governance is the control model that evaluates an identity at the point an action is about to happen, not only when access is first granted. For AI agents, it ties policy to tool use, routing, context, and accountability so the system governs what the actor does, not just who logged in.
• Operational Identity: An operational identity is a non-human or delegated actor that performs work inside enterprise systems and therefore needs ownership, entitlement scope, and lifecycle governance. In AI agent programmes, it is the unit that should be reviewed, monitored, and revoked when business purpose or authority changes.
• Continuous Authorisation: Continuous authorisation is the practice of re-evaluating whether an action should proceed based on current context rather than relying on a one-time access decision. In AI execution environments, it is the control that limits damage when the actor can move from one tool or API to another without human intervention.
• Delegated Execution Chain: A delegated execution chain is the path from the human initiator to the non-human actor, the orchestration layer, and the enterprise systems touched by the action. It matters because accountability and policy enforcement can break at any handoff if the chain is not explicitly mapped and attributed.

Deepen your knowledge

AI agent execution governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending lifecycle and authorisation controls beyond human users, it is worth exploring.

This post draws on content published by SecurEnds: AI security and runtime governance for agent-driven execution. Read the original.