Runtime security for AI agents in Microsoft Foundry needs inline controls

At a glance

What this is: This is Zenity’s analysis of runtime security for AI agents built on Microsoft Foundry, with the key finding that agent risk now emerges during execution rather than at prompt time.

Why it matters: It matters because IAM, PAM, and NHI programmes must account for agent decisions, tool invocation, and inline enforcement across model, data, and system access.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Zenity's analysis of runtime security for AI agents built on Microsoft Foundry

Context

AI agent runtime security is the control problem that appears when agents stop being demos and start making decisions in live enterprise workflows. In that state, the security question is no longer whether a prompt was safe, but whether the agent can be stopped when it chains actions, invokes tools, or reaches into data it should not touch.

For identity teams, this shifts the discussion from static permission design to execution-time enforcement. The article argues that traditional prompt-level checks and after-the-fact monitoring do not match the way agents behave once they are connected to SharePoint, OneDrive, APIs, databases, and SaaS systems across production environments.

Key questions

Q: How should security teams govern AI agents that can chain actions across enterprise systems?

A: Security teams should govern chained agent actions at runtime, not only at prompt submission. That means enforcing policy where the agent invokes tools, reaches data, or crosses system boundaries, because the risky event is the sequence of actions, not the initial request. IAM and NHI controls need to evaluate the current context before the next action executes.

Q: Why do prompt-level controls fail for AI agent security?

A: Prompt-level controls fail because they inspect a single input while the real risk emerges across multiple decisions and tool calls. An agent can begin with an acceptable prompt and still leak data, misuse tools, or expose secrets later in the action chain. Effective governance must assess the full execution path, not just the first instruction.

Q: What breaks when AI agents are only monitored after execution?

A: Post-execution monitoring breaks when the organisation needs prevention, not just evidence. By the time the alert exists, the agent may already have exposed data, invoked an internal API, or completed an unsafe tool action. Runtime governance needs inline blocking and contextual policy enforcement before the action completes.

Q: How do IAM and NHI teams decide where to place controls for AI agents?

A: They should place controls at each boundary where the agent can access models, tools, data, or enterprise systems. The objective is to make authorisation follow behaviour, not just account provisioning. That creates a practical governance layer for agent identity across the systems the agent can actually affect.

How it works in practice

Why prompt-level controls miss AI agent runtime risk

Prompt-level controls inspect a single input, but AI agents operate across a sequence of decisions, tool calls, and data accesses. Once an agent can chain actions, the risky moment is often not the prompt itself but the handoff between intention and execution. Runtime security sits inside that execution path, where it can inspect context, tool usage, and policy violations before the agent completes the next step. That is a different control plane from post-execution logging or model safety filters, which are useful but too late to prevent data movement or tool misuse.

Practical implication: put enforcement where the agent executes, not only where the prompt enters the system.

Inline prevention for secrets, data leakage, and tool misuse

Inline prevention matters because the highest-value failures for agents are operational, not theoretical. A runtime control can block sensitive data leakage, secret exposure, jailbreak attempts, and tool misuse before those actions complete. The key architectural point is that the control evaluates the agent’s behaviour in context, rather than judging isolated tokens or a one-time request. That makes it closer to an identity and access control than a content moderation layer, because it determines whether a specific action sequence is permitted in the current session.

Practical implication: treat agent runtime security as an access decision for each action chain, not as a content scan.

Agent-aware enforcement across models, tools, and enterprise systems

Agent-aware enforcement is needed because the risk surface spans more than one component. The article describes agents that connect to enterprise resources such as SharePoint, OneDrive, databases, SaaS platforms, and internal APIs. Security only holds if policy follows the agent across those boundaries, with continuous visibility into what it can reach and what it is trying to do. In practice, this creates an identity governance problem for machine behaviour: access is no longer just granted, it is exercised dynamically across multiple systems during runtime.

Practical implication: map every external tool and data path the agent can invoke, then enforce policy at each boundary.

NHI Mgmt Group analysis

Runtime security for AI agents is now an identity control problem, not a model-safety problem. The article shows that agents increasingly make decisions, chain actions, and invoke tools across live enterprise systems, which means the control point has moved from prompt review to execution-time governance. Traditional IAM and security tooling were designed to approve access requests, not to arbitrate each autonomous action as it happens. Practitioners should treat runtime enforcement as the new perimeter for agent identity.

Prompt-level controls fail because they assume the dangerous event is the request, when the dangerous event is the sequence. An agent can start with an acceptable prompt and still leak data, expose secrets, or misuse tools once it begins chaining actions. That makes the true security object the action graph, not the text input. For NHI and agentic programmes, the implication is that policy has to evaluate behaviour across the whole execution path, not only inspect the starting instruction.

Inline enforcement is a named concept worth keeping: execution-path control. The useful distinction is between tools that observe what happened and controls that decide whether the next action may occur. Execution-path control is what makes agent governance materially different from logging, alerting, or post-processing. Security teams should think of it as the difference between forensic visibility and live authorisation.

Foundry-connected agents collapse the gap between identity and data access. Once an agent can directly reach SharePoint, OneDrive, databases, SaaS platforms, and internal APIs, identity policy becomes inseparable from data-plane control. That matters because the same behavioural drift that creates a breach also creates compliance exposure. The practitioner conclusion is simple: agent identity must be governed at the point where access is exercised, not where it is provisioned.

Autonomy raises the bar for governance because the actor can choose both the action and the timing. This is where NHI programmes need to sharpen their understanding of agentic behaviour. When decision-making is runtime-driven, the security team is no longer protecting a static credential holder but a system that selects tools, sequences operations, and interacts with business systems on demand. The implication is that governance must follow runtime behaviour, not just assigned permissions.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• The governance gap is widening because AI agent deployment is accelerating even where oversight is still incomplete, as shown in Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

Execution-path control will become the operational dividing line for AI agent governance. Organisations that can only observe prompts will keep missing the moment when an agent turns policy into action across SharePoint, SaaS, APIs, and databases.

With 48% of organisations unable to track and audit the data their AI agents access, per AI Agents: The New Attack Surface report, the governance gap is already structural rather than hypothetical. That is why identity teams should align agent runtime controls with the same rigor used for high-risk NHI access paths.

The next programme priority is to treat agent identity as a live access surface, not a static configuration item. Security leaders should expect that prompt filtering, logging, and post-run review will remain necessary but insufficient once agents are allowed to reach business systems directly.

For practitioners

• Move enforcement into the execution path Place controls where the agent actually calls tools and reaches data, so policy can stop unsafe actions before data moves or systems are impacted.
• Map every agent tool and data boundary Inventory the enterprise systems, APIs, and repositories each agent can invoke, then attach policy checkpoints to those boundaries instead of relying on prompt filtering alone.
• Separate observation from prevention Keep logging and alerting for investigation, but add inline blocking for secret exposure, jailbreak attempts, and tool misuse so runtime threats are contained in session.
• Review agent governance as an access decision problem Align IAM, PAM, and NHI governance so each chained action is evaluated against current context, current purpose, and current system reach.

Key takeaways

• AI agent runtime risk is an access-control problem because the harmful event happens during action chaining, not at prompt submission.
• Only 52% of organisations can audit what their AI agents access, which leaves a large compliance and breach-investigation blind spot.
• Inline enforcement at the execution path is the control that can stop secret exposure, data leakage, and tool misuse before impact.

Key terms

• Execution-path control: Execution-path control is the practice of enforcing policy at the moment an agent takes action, not after the fact. It treats each tool call, data access, or chained step as an authorisation event, which is essential when agent behaviour unfolds dynamically across systems.
• Agent runtime security: Agent runtime security is the set of controls that protect AI agents while they are operating in live environments. It focuses on decisions, tool use, and data movement during execution, where prompt filters and model safeguards are too early or too late to prevent harm.
• Chained actions: Chained actions are the sequence of operations an AI agent performs after an initial instruction, such as querying data, invoking tools, and sending outputs to downstream systems. The security risk comes from the sequence as a whole, because each step can expand access or move data further than intended.
• Inline prevention: Inline prevention is a blocking control that intervenes before an unsafe action completes. For AI agents, it matters because the goal is not just to detect misuse later, but to stop secret exposure, unauthorised tool use, or data leakage while the session is still active.

Deepen your knowledge

AI agent runtime security is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are defining governance for agents that can make decisions and invoke tools in production, this is the right starting point.

This post draws on content published by Zenity: availability of inline agent runtime security for agents built on Microsoft Foundry. Read the original.