Runtime security for homegrown AI agents in Microsoft Foundry

At a glance

What this is: This is Zenity's analysis of runtime security for homegrown AI agents in Microsoft Foundry, with the key finding that agent risk emerges when tools, data, and actions converge during execution.

Why it matters: It matters because IAM, NHI, and agentic AI programmes now need controls that govern what an agent can do while it is acting, not just what it was allowed to do at provisioning time.

By the numbers:

• 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 Microsoft Foundry agents

Context

Homegrown AI agents change the security problem because they do not just call an API, they choose actions, invoke tools, and move information across systems while the workflow is running. That creates an identity governance gap for AI agent identity risk, because static policy and post-hoc monitoring were designed for predictable application behaviour, not runtime decision-making.

Microsoft Foundry is being used to move agents from experimentation into production, which means the question is no longer whether agents can be built, but whether their runtime behaviour can be governed safely. Zenity's framing is that inline control is the missing layer when agents can access enterprise data, chain tools, and execute actions inside business processes.

For security teams, the practical shift is from approving the build to controlling the moment of action. That affects agentic AI, NHI, PAM, and data governance at once, because the same runtime can expose secrets, cross trust boundaries, and trigger destructive operations if policy is only enforced before execution.

Key questions

Q: How should security teams govern AI agents that invoke tools in enterprise workflows?

A: Security teams should govern the runtime, not just the deployment. That means binding tool access, data sensitivity, and action approval to the agent's live context so the policy decision happens at the moment of execution. If the agent can choose, chain, and trigger actions, governance must inspect behaviour as it unfolds.

Q: Why do AI agents create a new identity governance problem for IAM teams?

A: AI agents create a new identity governance problem because they combine identity, action selection, and execution in one runtime. IAM controls built for users or service accounts assume the actor's intent is stable enough to review before or after the event. Agentic behaviour breaks that assumption by making the risk emerge mid-session.

Q: What breaks when prompt injection is not controlled in AI agent systems?

A: When prompt injection is not controlled, an attacker can redirect the agent's context, change tool use, and trigger unintended actions while the agent still appears trusted. The real failure is not just a bad output. It is the collapse of the boundary between acceptable input and authorised behaviour.

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.

Technical breakdown

Runtime enforcement at the agent control plane

Agent runtime security works by inspecting behaviour as the agent acts, not after the workflow ends. In practice, that means the control plane watches tool calls, data movement, and action chains in context, then blocks or constrains operations that violate policy. This is different from static application controls because the security decision depends on the live sequence of prompts, retrieved data, and selected tools. For enterprise agents, the important architectural shift is that authorization is no longer a one-time gate. It becomes a continuous decision loop tied to context, sensitivity, and intent signals.

Practical implication: place inline policy enforcement where the agent executes, not only where it is created or deployed.

Prompt injection, context poisoning, and agent hijacking

Prompt injection is not just a bad prompt, it is a runtime manipulation technique that pushes an agent away from its intended policy by altering the context it uses to decide. Context poisoning and memory manipulation extend that problem by contaminating the state the agent reuses across steps. Once that happens, the agent may follow malicious instructions while still appearing to operate normally. The technical risk is behavioral, not merely textual: the agent can be driven into unsafe tool use, destructive output, or unauthorized data exposure even if the original system prompt was sound.

Practical implication: inspect behavioural drift across action chains, not just prompt content at the input boundary.

Tool invocation and secret exposure in agent workflows

Agents become risky when they can invoke tools and carry credentials at the same time. Each tool call expands the blast radius because access to data, APIs, and secrets can be combined in ways the original workflow designer did not anticipate. That is why least privilege in agentic systems has to be evaluated dynamically, based on current context and action path, not only on preassigned permissions. If a secret is available to the agent, the security question is whether the current context still justifies that access, especially when untrusted data has already entered the session.

Practical implication: bind tool access and secret exposure to live context, and remove privileges when untrusted input enters the session.

Threat narrative

Attacker objective: The attacker wants to hijack an otherwise trusted AI agent so it leaks secrets, crosses boundaries, or performs destructive actions at runtime.

1. Entry occurs when an attacker injects malicious prompts or poisoned context into an agent session that is already trusted to operate inside enterprise workflows.
2. Credential access follows when the agent is tricked into invoking tools, revealing secrets, or reusing authentication material across connected systems.
3. Escalation happens when the manipulated agent chains actions, crosses contexts, or performs destructive operations that were never intended by the original operator.
4. Impact is achieved when the agent exfiltrates data, triggers unauthorised actions, or causes operational damage inside business systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Inline controls matter because static approval models assume the risky event happens before execution. This article shows the opposite: the security decision occurs while the agent is already operating, already carrying context, and already able to act. That breaks the assumption that authorization can be completed at provisioning time, and it is exactly why post-hoc monitoring is too late for agentic workflows. Security teams should re-evaluate whether their current IAM and PAM patterns can even observe the decision point they claim to control.

Prompt injection is the named concept that best captures the new runtime failure mode. In agentic systems, malicious input does not merely manipulate text generation, it redirects tool use, memory, and action sequencing. That turns context into an attack surface and makes the context window part of the privilege boundary. Practitioners should stop treating the prompt as a front door problem and start treating runtime context as a governance domain.

Least privilege becomes dynamic policy, not a provisioning artifact. Agents that retrieve data from SharePoint, OneDrive, APIs, and SaaS systems can combine those permissions in ways that outstrip the original design intent. The governance gap is not simply over-privilege, but over-composition, where individually valid permissions become unsafe when chained together by an autonomous runtime. Security leaders should evaluate how much privilege is still safe once actions are sequenced by the agent itself.

Secret exposure at the agent layer exposes a blind spot in conventional NHI controls. Traditional NHI tooling can manage credentials, but it does not by itself understand whether an agent should be allowed to surface, reuse, or pass those secrets at runtime. That leaves a policy gap between identity issuance and action-level use. Practitioners should align NHI governance with agent-aware enforcement so secrets are governed in the same moment they are consumed.

From our research:

• 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.
• For a broader view of how machine identity gaps show up in real incidents, see 52 NHI Breaches Analysis, which maps recurring failure patterns across exposed credentials and standing access.

What this signals

Prompt injection has become the practical bridge between agentic AI and NHI governance. Once agents can invoke tools and carry secrets, the familiar machine-identity problem becomes behavioural rather than static, because the same credential can be used safely in one context and dangerously in the next. Teams that already track NHI sprawl should now ask which agent actions are created, combined, and consumed at runtime under OWASP Agentic AI Top 10 style risk categories.

The governance signal is clear: runtime visibility, not just issuance control, is becoming the differentiator between pilot-stage agent deployments and production-grade use. That shift also changes how you read policy effectiveness, because the question is no longer whether access exists, but whether the system can still validate the action before it reaches enterprise data or connected tools.

Ephemeral privilege composition: agent security now depends on how permissions combine during a single workflow, not just on whether any one permission is excessive. That makes agent governance closer to continuous authorization than traditional entitlement review, and it pushes programme owners toward controls that understand context, data sensitivity, and action sequencing together.

For practitioners

• Map agent runtime as an identity surface Document every place the agent can choose an action, invoke a tool, or move data across trust boundaries. Treat those moments as governance checkpoints for identity, privilege, and data sensitivity.
• Bind tool use to live context Restrict tool invocation when untrusted data enters the session, and require policy evaluation against the current context window before any destructive or cross-system action can execute.
• Separate secret access from general agent capability Keep credentials, tokens, and API keys outside broad agent memory wherever possible, and revoke them from the current workflow path when the task no longer requires them.
• Review whether existing IAM and PAM controls see the decision point Check whether your access reviews, approvals, and monitoring are built to catch runtime behaviour or only predeployment state. If they cannot see the agent's live decision path, they are governing the wrong layer.

Key takeaways

• AI agents create a runtime identity problem because they can change behaviour while already operating inside enterprise workflows.
• The scale of the issue is visible in the broader NHI market, where 1 in 4 organisations are already funding dedicated controls and most others are still planning to catch up.
• Runtime policy enforcement is the control that matters here, because static approval and post-hoc monitoring cannot reliably stop tool misuse, secret exposure, or agent hijacking in motion.

Key terms

• Agent Runtime Security: Agent runtime security is the control layer that evaluates an AI agent while it is acting, not only when it is built or deployed. It focuses on tool use, context, and action sequencing so policy can stop unsafe behaviour before it reaches enterprise systems.
• Prompt Injection: Prompt injection is a manipulation technique that steers an AI system away from its intended behaviour by altering the instructions or context it relies on. In agentic environments, the impact is broader because the manipulated context can drive tool calls, data access, and destructive actions.
• Context Window: The context window is the live information set an AI system uses to decide what to do next. For agents, it becomes part of the control problem because untrusted data inside that window can change tool choice, privilege use, and execution path in ways static policy never anticipated.
• Dynamic Least Privilege: Dynamic least privilege is the practice of adjusting access based on the current task, data, and runtime state rather than fixed provisioning alone. For AI agents, the same permission can be safe in one step and excessive in the next, so the policy must move with the workflow.

Deepen your knowledge

AI agent runtime security is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for agents that can invoke tools and touch enterprise data, it is worth exploring.

This post draws on content published by Zenity: Securing Homegrown Agents in Runtime: The Value of Zenity + Microsoft Foundry. Read the original.