TL;DR: Enterprises using Microsoft Foundry are moving AI agents into production, but the real risk appears at runtime when agents chain actions, invoke tools, and cross data boundaries, creating new exposure for prompts, secrets, and unauthorized actions, according to Zenity. Static application controls are not enough once agents gain agency, and inline runtime enforcement becomes the decisive governance model.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Zenity's blog post: Microsoft Foundry agent security has to be enforced at runtime because the material risk appears only when agents begin chaining actions, invoking tools, and crossing data boundaries.
Why it matters: That matters to IAM, IGA, PAM, and NHI practitioners because agent behaviour changes the control point from provisioning-time trust to execution-time governance, where policies must inspect actions before they complete.
Context
Microsoft Foundry is being used to build homegrown AI agents that can reason, call tools, access enterprise data, and automate workflows. The security problem is that these agents do not stay inside a fixed request-response model, so the governance assumptions behind static application controls and post-hoc monitoring start to fail as soon as the agent begins acting.
For identity teams, the important shift is not simply that the workload is AI-based. It is that the actor is making runtime decisions across systems and data sources, which means permissioning, monitoring, and policy enforcement have to follow execution rather than sit only at creation time. That is the control gap this article is really about.
Zenity’s core claim is that protection has to occur where the agent actually acts, not where the agent was configured. That makes this a runtime governance problem for agentic AI identity, with direct consequences for authorization, data handling, and tool use.
Key questions
Q: What breaks when Microsoft Foundry agents are governed like normal applications?
A: Static application governance breaks because the important security decision happens during agent execution, not just at deployment. Once an agent can chain actions, invoke tools, and change behaviour based on context, post-hoc monitoring arrives too late. Teams need runtime controls that can inspect and stop the action before it completes.
Q: Why do agent tool calls increase identity and access risk?
A: Tool calls turn an agent into an active privilege consumer rather than a passive workload. Each invocation can cross data boundaries, trigger side effects, or expose secrets, so the effective access scope becomes larger than the original configuration. That is why runtime authorization and context-aware policy matter more than static assignment alone.
Q: What are the signs that agent runtime security is failing?
A: The clearest signs are unsafe tool selections, repeated attempts to move data across boundaries, secrets appearing in prompts or outputs, and agent actions that ignore expected policy context. If those behaviours are only visible after the fact, the control model is already behind the attack surface.
Q: What should teams do when an agent can access sensitive tools or data?
A: They should reduce scope before production use, separate high-risk tools from low-risk ones, and require explicit approval for any action with external impact. If the workflow cannot be safely constrained, the access model is too permissive for an agentic system.
Technical breakdown
Why agent runtime breaks static application security
Traditional application security assumes the important security decision happens before execution or at well-defined API boundaries. Agentic systems do not behave that way. A Microsoft Foundry agent can reason over context, choose a tool, and then decide whether to continue, branch, or combine actions based on what it sees. That introduces behaviour that is adaptive rather than pre-scripted, which makes post-hoc logging too late for containment. The security model has to inspect action intent and context at the moment of execution, not after the chain has already touched enterprise systems.
Practical implication: move policy enforcement to runtime checkpoints that can stop an agent before a tool call completes.
Tool invocation and cross-context data flow
Tool use is the control plane of many agents. In Foundry, the agent can reach into SharePoint, OneDrive, APIs, and internal systems, which means every invocation becomes both an access event and a data movement event. The risk is not just data exposure. It is unsafe cross-context sharing, where untrusted or tainted context changes what the agent is allowed to do next. That is why inline policy needs to combine data sensitivity, identity context, and action inspection. The issue is not that tools exist. The issue is that the agent can combine them dynamically in ways that static entitlements do not anticipate.
Practical implication: treat each tool call as a governed authorization decision, not as a routine application function.
Secrets exposure in agent workflows
Agents often need credentials, tokens, or API keys to complete tasks, but those secrets become far more fragile when they move through prompts, outputs, memory, or chained workflows. In a static workload, a secret is usually exposed through a narrow misuse path. In an agentic workflow, the secret can be surfaced indirectly through context poisoning, prompt manipulation, or careless propagation across tools. That creates a gap between conventional NHI governance and agent-layer protection. The core problem is not only secret storage. It is secret handling during runtime interaction, where the agent itself becomes a potential disclosure path.
Practical implication: isolate secrets from agent-visible context and deny any workflow that allows secrets to reappear in prompts or outputs.
Threat narrative
Attacker objective: The attacker aims to steer the agent into unsafe execution so it leaks data, exposes secrets, or performs unauthorized actions across connected enterprise systems.
- Entry occurs when a malicious prompt, poisoned context, or unsafe data source is introduced into the agent’s working context.
- Credential access or abuse follows when the agent is manipulated into invoking tools or exposing secrets, tokens, or authentication data.
- Escalation happens as the agent chains actions across enterprise systems and crosses data boundaries without a human approval gate.
- Impact is reached when the agent executes unauthorized or destructive actions, including data leakage, unsafe API calls, or production damage.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime enforcement is now the governing boundary for agentic AI identity. Microsoft Foundry agents do not fail safely just because they were configured correctly at build time. Once agents can chain actions and invoke tools dynamically, the decisive control point moves to execution, where policy must evaluate what the agent is about to do. The practitioner takeaway is that provisioning-time trust is no longer sufficient for production agent governance.
Tool use turns every agent into a policy decision engine. The moment an agent can select tools and combine them across business systems, access control stops being a static entitlements problem and becomes an operational authorization problem. This is where NHI concepts such as least privilege remain necessary but incomplete, because the runtime context can change the effective scope of access. Practitioners should treat agent tool invocation as governed privilege, not application convenience.
Ephemeral credential trust debt is the right concept for this architecture. Secrets, tokens, and API keys given to agents are often assumed to be safe because they are short-lived or scoped. That assumption fails when the agent can expose, propagate, or misuse them within a single runtime session. The implication is that identity governance has to account for how quickly trust can be created, consumed, and leaked before any review cycle can intervene.
Access review processes assume access persists long enough to be reviewed; autonomous agent workflows can consume and discard privilege inside one task. That assumption fails when the actor is not a passive workload but an active runtime decision-maker. In practice, this means governance models built around periodic certification cannot be the primary control for agentic systems. The practitioner conclusion is that authorisation has to be validated at the moment of use.
Agentic AI security and NHI governance are converging at the same control plane. Foundry agents are neither purely human identities nor ordinary service accounts, and that creates a category problem for control ownership. The article shows why runtime observability, inline blocking, and policy enforcement need to be coordinated across IAM, PAM, and NHI teams rather than left in separate silos. The practitioner takeaway is to align governance around the actor’s runtime behaviour, not the product boundary.
From our research library:
- 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.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Security Guide
What this signals
Inline runtime enforcement is becoming the default control model for agentic systems. Security teams should expect more agent platforms to move from static policy checks toward continuous decisioning at the moment of tool use. That change matters because the control boundary shifts from build time to execution time, which affects how IAM, PAM, and NHI teams define ownership.
Access reviews alone will not govern agentic behaviour. Review cycles assume privilege stays stable long enough to be observed and certified, but agent workflows can consume access inside a single task. Identity programmes will need issuance-time controls, runtime telemetry, and containment rules that act before the workflow completes.
Secret handling becomes part of the runtime trust boundary. When agents can see, pass, or infer credentials during execution, the problem is no longer secret storage alone. Governance has to decide which workflows are allowed to surface authentication material at all, and which must be blocked before they can create spillover risk.
For practitioners
- Enforce runtime policy at the tool layer Block or allow agent actions at the moment of invocation, using context, identity, and data sensitivity as the decision inputs.
- Classify agent-visible data before execution Label enterprise data that agents can reach so untrusted or tainted context cannot be chained into destructive actions.
- Separate secrets from conversational context Prevent tokens, credentials, and API keys from appearing in prompts, outputs, memory, or cross-agent workflow state.
- Audit privilege assumptions for Foundry agents Review which authorizations were granted for static workloads but now expand too far once the agent can choose tools dynamically.
- Define containment triggers for unsafe agent behaviour Set conditions that stop an agent when it attempts cross-context sharing, destructive action, or repeated tool misuse.
Key takeaways
- Microsoft Foundry agent security is no longer just an application design problem because the main risk appears when agents act, not when they are created.
- The article links agent runtime behaviour to data leakage, prompt manipulation, unsafe tool use, and secret exposure across enterprise systems.
- Practitioners need inline enforcement, runtime containment, and tighter secret handling if they want agentic AI to operate in production safely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centres on agents invoking tools at runtime and the resulting misuse risk. |
| ASI03 — Identity & Privilege Abuse | Foundry agents gain effective privilege through dynamic action chains and context-driven access. | |
| Recommendation — Enforce tool-use policy at runtime and block any invocation that exceeds the agent's approved scope. Constrain agent privilege with context-aware authorization and deny escalation across chained actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article explicitly discusses secret and credential exposure through prompts and workflows. |
| NHI-05 — Overprivileged NHI | Agents are described as receiving more access than static workflows need once they act dynamically. | |
| Recommendation — Remove secrets from agent-visible context and detect any workflow that can surface credentials in output. Audit agent permissions for excess scope and reduce any standing access that is not needed at runtime. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling agent actions through permissions and entitlements at execution time. |
| Recommendation — Apply PR.AA-05 to validate agent entitlements at the moment of use rather than only at provisioning. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | Prompt-driven agent abuse leads to secret exposure and destructive impact across connected systems. |
| Recommendation — Map malicious agent behaviour to credential access and impact techniques in detection and response planning. | ||
Key terms
- Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
- Tool Invocation: Tool invocation is an action where an AI agent calls an external system such as a database, API, or file service. Each invocation should be treated as an auditable identity action because it is the point where the agent can move data, trigger changes, or widen its reach across the environment.
- Agent-Visible Secrets: Agent-visible secrets are credentials, tokens, or API keys that can be exposed to an agent during execution through prompts, memory, outputs, or workflow state. Once secrets become visible to the agent, they are part of the runtime trust boundary and can be leaked or misused.
- Cross-Context Data Sharing: Cross-context data sharing happens when an agent moves information between systems, tasks, or trust zones that were not meant to exchange it. In Foundry-style workflows, the risk is not just access to data, but the agent combining data in ways that create new exposure or unsafe action paths.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org