Runtime security for AI agents in Microsoft Foundry needs inline controls

At a glance

What this is: Zenity’s announcement focuses on inline runtime security for AI agents in Microsoft Foundry, arguing that production risk now emerges during execution rather than at prompt entry or after the fact.

Why it matters: For IAM, PAM and security teams, this matters because agent behaviour now has to be governed at runtime, where tool calls, data access and chained actions can outpace traditional review and policy checkpoints.

Context

AI agent runtime security is about controlling what an agent can do while it is executing, not just what it is allowed to ask for. In this announcement, the security problem is the gap between agent autonomy in production and controls that were built for prompts, static policies or post-execution review.

Zenity frames Microsoft Foundry deployments as increasingly connected to enterprise resources such as SharePoint, OneDrive, databases, SaaS platforms and internal APIs. That connectivity increases the governance burden because misconfiguration, manipulation or abuse can now translate into immediate data movement, tool invocation and downstream impact.

The central issue for identity programmes is that agent decision-making creates a runtime policy boundary. When the control point sits outside the execution path, security teams lose the ability to stop sensitive actions before they happen.

Key questions

Q: What breaks when AI agents are not governed at runtime?

A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context. That is where tool chaining, MCP connections, and rapid decision-making become dangerous. Static approval cannot stop a live change in intent, so teams lose control at the point of action.

Q: Why do AI agents need runtime enforcement instead of relying only on upstream identity controls?

A: AI agents can decide and act dynamically inside the execution loop, so upstream authentication alone does not control every tool call or data request. Runtime enforcement reduces the chance that a valid identity can overreach its intended scope. This matters most when agents operate across changing contexts, multiple tools, and short-lived tasks that require continuous policy checks.

Q: What are the signs that agent authority is failing in production?

A: Look for long-lived tokens, shared credentials, missing approval logs, and audit trails that cannot attribute an action to the agent itself. If a team cannot tell who or what issued a delete, config change, or external message, governance is already failing.

Q: How should organisations balance prompt filters and runtime controls for AI agents?

A: Use prompt filters to reduce obvious abuse, but treat runtime controls as the primary enforcement layer. Prompt screening cannot reliably manage tool misuse, chained actions or secret exposure once an agent is active. The right model is layered control, with inline prevention carrying the final decision authority.

How it works in practice

Why prompt-level controls miss agent runtime behaviour

Prompt-level controls examine what a user or agent asked for before execution begins, but agent risk often appears after the prompt is accepted. An AI agent can chain actions, choose tools and move data across systems in ways that were not fully visible at input time. That makes the execution path, not the prompt text, the real control boundary. Inline security works by observing the agent as it acts, so the policy decision can be made against the live sequence of tool calls, data access and context changes instead of a static request. In practice, this is the difference between approving intent and governing behaviour.

Practical implication: place policy enforcement where the agent executes, not only where the prompt is received.

How tool invocation expands the attack surface

When agents can invoke enterprise tools directly, every connected system becomes part of the security surface. SharePoint, OneDrive, databases, SaaS platforms and internal APIs all become potential paths for overreach if the agent is misconfigured or manipulated. The technical risk is not just data theft, but tool misuse, secret exposure and unauthorized chaining across systems. Inline enforcement is meant to inspect those interactions as they happen and interrupt unsafe transitions before the next tool executes. That is materially different from logging after the fact, because the damage can already be done by the time a post-execution control sees the event.

Practical implication: inventory every tool-connected system as part of the agent control boundary.

Why agent-aware enforcement changes governance

Agent-aware enforcement evaluates decisions and chained actions rather than isolated prompts. That matters because autonomous behaviour is defined by runtime choice, not by a fixed script. Once an agent can decide what to do next, governance has to account for behavioural drift, not just permission assignment. The model implied here is closer to continuous authorization than one-time approval. Security teams therefore need controls that understand context, intent and sequence, because a single prompt may lead to multiple actions with different risk profiles. This is the point where traditional guardrails become too coarse for production use.

Practical implication: treat agent behaviour as a continuous authorization problem rather than a one-time access decision.

NHI Mgmt Group analysis

Inline runtime enforcement is now the control plane that matters for AI agents. The article shows why prompt-time filtering and post-execution logging are both too early and too late for production agents. Once an agent can decide, chain and invoke tools inside a live session, the decisive governance question becomes whether unsafe action can be blocked before the next execution step. The practitioner implication is that runtime becomes the primary security boundary for agentic systems.

Agentic behaviour collapses the assumption that access can be governed as a static entitlement. Least privilege was designed for actors whose access scope can be defined in advance and then reviewed later. That assumption fails when the agent’s next action is determined at runtime, because the access path is created as the task unfolds. The implication is that identity governance for agents has to be anchored in live behavioural control, not only in provisioning records.

Runtime security for AI agents is becoming an identity governance problem, not just an application security problem. The article links agent misuse to enterprise resources, secrets and tool invocation, which means the control surface crosses application, data and identity boundaries at once. That is why NHI governance, PAM thinking and agent policy enforcement now intersect. Practitioners should treat agent runtime controls as part of the broader identity stack, not as a niche AI add-on.

Foundry-style agent deployments expose a new governance gap: the execution path has become the point of trust. If security controls sit outside the path, they can only observe or react after the agent has already acted. That makes compliance, audit and operational assurance dependent on inline evaluation of decisions and chained actions. The field should expect more pressure to move from policy documents to enforced runtime control.

Agent misuse is the visible symptom, but the deeper issue is behavioural opacity at runtime. Security teams can no longer assume that a prompt, a policy or a role assignment tells them enough about what the agent will do next. That breaks the old comfort model for both IAM and application governance. The practical conclusion is that agent systems need controls that can reason over sequence, context and tool choice in real time.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

Execution-path governance is becoming the practical dividing line for AI agent security. Organisations that keep treating agents like static applications will miss the point that access, tool choice and action sequence now unfold together at runtime. The result is a governance gap that can only be closed with inline enforcement, not retrospective review.

Agent runtime control is also an identity control. Once an agent can invoke enterprise systems, identity teams have to decide when authorisation is evaluated, what context counts and which actions can be blocked before they complete. That shifts the programme from entitlement management to live behavioural governance.

Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. That mismatch suggests runtime security will become a baseline expectation faster than most governance programmes are prepared for.

For practitioners

• Define the execution path as the control boundary Map where agents actually run, where they call tools and where data can leave the session, then enforce policy at those points rather than only at the prompt or after execution.
• Classify every connected system the agent can reach Inventory enterprise resources such as databases, SaaS platforms, internal APIs and collaboration tools so each dependency is covered by a runtime access decision.
• Separate prompt safety from runtime authorisation Keep prompt screening and content policy checks, but do not treat them as substitutes for inline prevention when agents can chain actions or invoke tools.
• Require behavioural enforcement for sensitive actions Use controls that can inspect decisions, tool choice and chained actions before data moves or a downstream system executes.

Key takeaways

• AI agent security now depends on controls that operate during execution, because prompt-level and post-execution methods cannot reliably stop tool misuse or unsafe chaining in time.
• The article frames Foundry-connected agents as a broad enterprise governance issue, since their access to collaboration tools, databases, SaaS platforms and APIs expands the runtime attack surface.
• Inline enforcement changes the control model from static permissioning to live behavioural governance, which is the only way to keep agent autonomy within acceptable bounds.

Key terms

• Inline Agent Runtime Security: Inline agent runtime security is the practice of evaluating and enforcing policy while an AI agent is executing, not before it starts or after it finishes. It focuses on live decisions, tool calls and data movement so unsafe behaviour can be blocked in the execution path.
• Tool Execution Path: A tool execution path is the route through which an AI agent invokes an external action, such as a command, API call, or workflow step. If that path is not tightly authorised, a model can be used to trigger actions beyond the intended user boundary. The control problem is usually privilege scope, not the model itself.
• Agent-Aware Enforcement: Agent-aware enforcement means the control layer evaluates the agent’s context, intent and chained actions rather than treating each prompt as an isolated request. For autonomous or semi-autonomous agents, that distinction is critical because risk emerges from sequence, not single messages.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.