AI execution needs runtime identity governance, not static trust

At a glance

What this is: This analysis argues that AI agents are becoming execution identities, not just generation tools, and that static trust and one-time authentication no longer match how they operate.

Why it matters: IAM, PAM and NHI teams need runtime governance because agent-driven execution changes who acts, when access is exercised, and how entitlement risk must be enforced.

Context

AI agent execution is the point at which a model-backed system stops producing suggestions and starts performing actions. In this article, SecurEnds frames that shift as an identity governance problem because the acting entity is no longer only the human user but the agent operating on that user's behalf.

The gap is that most enterprise controls still assume access is granted to a stable identity, reviewed later, and observed through conventional logs. Once an agent can invoke APIs, route through MCP, and make runtime decisions, governance has to follow the action path rather than the login event.

Key questions

Q: What breaks when AI agents are governed with static zero trust assumptions?

A: Static zero trust assumptions break when the agent can plan, remember, and reroute its own actions mid-session. The result is a control model that knows the network path but not the decision-making actor, which weakens least privilege and incident investigation at the same time.

Q: Why do AI agents need runtime controls instead of only pre-approved access?

A: Pre-approved access cannot tell you what the agent will do once prompts, tools, memory, and sub-agents start interacting. Runtime controls matter because the risky event is the action itself, not the entitlement on paper. If the workflow can change mid-session, the control must be able to intervene mid-session too.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: How should security teams govern employee AI use without blocking productivity?

A: Start with visibility into sanctioned and shadow AI use, then apply runtime policies that inspect intent and context rather than only keywords. The goal is to allow legitimate work while preventing sensitive data from leaving controlled boundaries. Teams usually need ownership, approved models, and enforceable logging before they can scale access safely.

How it works in practice

Why static trust fails for AI agent execution

Traditional access control assumes the identity presenting credentials is the same entity whose intent and behaviour can be inferred from the initial login. AI agent execution breaks that model because the human provides intent once, then the agent selects actions, tools, and timing at runtime. That creates a control problem that is closer to delegated machine execution than to human session management. The security question shifts from whether access was granted to whether each action remains appropriate in context. Practical implication: governance has to move from session approval to per-action authorisation for agent-driven workflows.

Practical implication: Move authorisation from login time to the point of action for every agent-driven request.

How identity, visibility and control work together in runtime governance

The article describes a three-layer model: AI identity governance, execution visibility, and real-time policy enforcement. Identity tells you who owns the agent, what authority it inherits, and what systems it may touch. Visibility ties agent-to-tool and agent-to-API activity back to identity and routing context so that telemetry becomes attributable. Control evaluates each request against identity context, routing context, tool sensitivity, and behavioural risk before allowing, challenging, or denying the action. Without all three layers, organisations either overtrust the agent or see activity too late to intervene. Practical implication: design governance so attribution and enforcement are linked, not separate.

Practical implication: Tie agent ownership, activity traceability, and enforcement into one runtime governance path.

What MCP and orchestration change for security teams

MCP and orchestration layers make agent execution more modular, but they also add routing complexity that weakens simple permission checks. A request is no longer just 'user to application'; it may pass through an agent, an orchestration layer, an MCP server, and then a tool or API. Each hop changes the trust boundary and the audit path. That means security teams cannot treat tool calls as generic API traffic, because the security question includes which agent routed the call, whether the path is expected, and whether the execution pattern matches the agent's normal role. Practical implication: map the full delegation chain before deciding how to enforce policy.

Practical implication: Inventory the delegation chain from human intent to tool execution before setting policy boundaries.

NHI Mgmt Group analysis

Static trust is the wrong governing assumption for AI agent execution: One-time authentication was designed for identities whose actions are bounded by a session and observable by a human operator. That assumption fails when the actor is an AI agent because execution continues after login, decisions are made at runtime, and the human is no longer present at each action boundary. The implication is that identity governance must be redesigned around delegated execution, not session trust.

AI agents are operational identities, not just application features: Once an agent can invoke APIs, route work through MCP, and perform enterprise actions, it becomes part of the identity plane. That means ownership, entitlement scope, and offboarding are governance requirements, not optional metadata. Treating agents as invisible automation creates a blind spot that human IAM controls were never designed to absorb.

Runtime visibility only matters when it preserves identity context: Telemetry that says an API was called is not enough when the real question is which agent initiated the call, which human supplied the intent, and what route carried the request. Without that chain, the organisation has activity logs but not accountability. The practitioner lesson is that execution visibility must be identity-linked or it will remain operationally interesting but security-poor.

Policy enforcement is moving from access entitlement to action approval: Traditional IAM asks whether an identity has standing access. AI execution asks whether the next action should be allowed right now, given routing, sensitivity, behavioural history, and risk. That is a different governance problem, and it sharpens the need for real-time decisioning on the exact action rather than broad permission grants.

Identity blast radius is now determined by delegated behaviour, not just privilege count: A low-privilege agent that can chain actions across tools can create more exposure than a larger human account with predictable behaviour. The governance challenge is no longer only how much access exists, but how far an agent can move once it starts executing. Practitioners should measure blast radius as a function of runtime autonomy, not entitlement inventory alone.

From our research library:

• 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
• Read next: AI Agent Authorisation Guide

What this signals

Identity governance now has to cover execution, not just entitlement: When an AI agent becomes the acting identity, the control problem shifts from who logged in to what the agent did, when it did it, and whether the action was still justified at runtime. Programmes that stop at access provisioning will miss the point where risk is actually created.

AI execution turns static authorisation into a runtime control issue: SecurEnds' framing fits a broader pattern in which 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey. That gap matters because runtime governance becomes the only reliable boundary once delegation outlives the login event.

For practitioners

• Define ownership for every AI agent Record the business owner, delegated authority source, and allowed systems for each agent so governance does not start from an anonymous runtime identity.
• Enforce per-action authorisation Require the policy engine to evaluate each sensitive API call, tool invocation, or workflow step at runtime instead of relying on initial login trust.
• Link execution logs to identity context Preserve the human initiator, agent identity, routing path, and target tool in the same record so investigators can reconstruct who caused what.
• Set offboarding rules for AI identities Remove agent entitlements and routing permissions when the use case, owner, or delegated task changes, not only when a system is retired.

Key takeaways

• AI agents are no longer just assisting users. They are becoming runtime actors whose decisions and tool use create identity risk that static trust cannot handle.
• The central weakness is not visibility alone. It is the gap between delegated intent and per-action authorisation when execution happens continuously and at machine speed.
• Practitioners need ownership, attribution, and policy enforcement tied together at runtime, or AI execution will remain outside the governance model.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.