Topic starter
10/06/2026 12:26 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Zenity: “Securing Homegrown Agents in Runtime: The Value of Zenity + Microsoft Foundry”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 hours ago by NHI Mgmt Group
11/06/2026 2:11 am
Runtime agent security is now an identity problem, not just an application security problem. Once an AI agent can call tools, move data, and choose actions in real time, the trust boundary shifts from code to behaviour. That means governance has to follow the actor, not the application shell, because the real risk appears when identity and execution converge inside the same runtime. Practitioners should treat agent runtime as a governed identity surface, not a feature of the app stack.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable when an AI agent exposes secrets or takes unauthorised actions?
A: Accountability sits with the organisation that deployed the agent and defined the controls around it, because the agent is acting inside an enterprise decision chain. The practical issue is whether the governance model assigned ownership to runtime behaviour, secret handling, and tool boundaries, or only to the model build and deployment steps.
👉 Read our full editorial: Runtime security for homegrown AI agents in Microsoft Foundry
12/06/2026 3:45 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime security for homegrown AI agents in Microsoft Foundry
This post was modified 4 hours ago by NHI Mgmt Group