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.
Why normal application governance is the wrong control model for Foundry agents
Microsoft Foundry agents are not just another software release to be approved once and then watched passively. Their security posture changes while they run, because they can decide, branch, call tools, and pursue a task differently as context changes. That means the control point moves from deployment paperwork to runtime authority, action inspection, and fast intervention before an unsafe step completes.
A normal application model assumes the important risk is whether the code and configuration shipped cleanly. For an agent, the more important question is what it is allowed to do at the moment it acts. That is why runtime policy, delegated authority, and per-action approval matter more than static sign-off. NHIMG’s AI Agent Authorisation Guide is useful here because it frames agent permission as task-scoped and decision-by-decision, not as a one-time launch condition.
This also changes the meaning of “governed.” If governance only checks the agent at build time, the control is already stale once the agent starts chaining tools or adapting to new context. The practical issue is not whether the agent exists, but whether each meaningful action still has a policy gate attached to it. That is the difference between managing software and managing delegated execution authority.
What breaks in practice when governance stays static
The main breakage is timing. Static controls can review configuration, model selection, and deployment approval, but they cannot reliably stop a harmful action that appears only after the agent has assembled context, chosen a tool, or inferred a new path. A Foundry agent can begin with a safe-looking task and end up performing a materially different sequence if the environment, prompt, or tool output changes.
That creates failure in three places. First, monitoring becomes retrospective, so alerts arrive after data has moved or an external side effect has happened. Second, accountability becomes blurred, because the meaningful decision may have been made by a runtime chain rather than by the original deployment owner. Third, least privilege erodes if standing access is broad enough to cover every possible branch the agent might take.
NHIMG’s AI Agent Observability, Audit and Incident Response Guide is relevant because it treats logging, attribution, and kill-switch design as operational necessities, not nice-to-have telemetry. If you cannot explain what the agent attempted and stop it in time, post-hoc governance is only documentation.
NHIMG’s Zero Trust for AI Agents also aligns with the core problem: trust has to be revalidated per request, and standing privilege should be removed wherever the agent can make externally visible changes. That is the opposite of a traditional “approve once, operate freely” model.
What control pattern replaces normal application governance
The control pattern is runtime governance, meaning policy decisions sit in the path of the action, not around the release artifact. In practice, that means checking the principal, the request, the tool, and the effect before the action is allowed to continue. It also means designing for containment, so a failed or suspicious action does not cascade into broader access, wider data exposure, or irreversible side effects.
For Foundry agents, the most useful governance questions are operational rather than architectural. Can the agent be constrained to the specific task it was assigned? Can high-impact actions be blocked until a policy engine or human approver confirms them? Can the system attribute each action clearly enough to support incident response and rollback? If the answer is no, the governance model is still too static.
NHIMG’s AI Agents vs Agentic AI helps separate simple assistant behaviour from genuinely autonomous execution. That distinction matters because the more an agent can sequence tools and adapt its plan, the less useful a normal application approval model becomes.
For organisations comparing tools and control design, NHIMG’s Agent Identity Standards Tracker is a good navigation point for the surrounding identity and authorization ecosystem. It helps teams understand where runtime trust signals, delegation patterns, and identity standards are heading, which is important when governance must operate at execution time rather than only at registration time.
Risk and Threat Considerations
When Foundry agents are managed like ordinary applications, the main risk is overtrust. An attacker, a malformed input, or simply an unexpected context shift can push the agent into an action path that the deployment review never anticipated. The result is not just a policy violation, but a live execution window where tool use, data access, or external actions can proceed before anyone can intervene.
Failure mechanism: Static approval leaves runtime actions insufficiently constrained, so the agent can use legitimate access in an unsafe sequence or with unsafe scope.
Impact: Teams lose the ability to prevent harmful actions in time, which increases the chance of unauthorized changes, data exposure, privilege abuse, and hard-to-reconstruct incidents.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Foundry agents governed like apps fail when runtime authority exceeds intended privilege. |
| ASI02 — Tool Misuse | The question centers on agents chaining tools and acting beyond static approval. | |
| ASI08 — Cascading Failures | Static governance fails when one agent action triggers broader downstream impact. | |
| Recommendation — Enforce per-action authorization and narrow agent privilege before tool use proceeds. Gate tool calls at runtime and block unsafe sequences before execution continues. Contain agent blast radius so one bad action cannot propagate across systems. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agents need narrowly scoped runtime access instead of broad standing permissions. |
| AU-6 — Audit Review, Analysis, and Reporting | Runtime decisioning demands actionable logs and attribution for agent actions. | |
| Recommendation — Constrain each agent to the minimum permissions required for the current task. Log and review agent actions so unsafe execution can be detected and investigated. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The subject requires continuous verification of each agent request and action. |
| Recommendation — Verify the principal and request continuously before allowing each agent action. | ||
Practitioner Guidance
What to verify: Confirm that high-impact agent actions are enforced by runtime policy, not just by deployment approval or code review. If an action can change state, access data, or invoke another tool, there should be a live decision point before completion.
Decision rule: If the agent can materially affect systems outside its immediate context, treat standing access as a design defect and require task-scoped permissions, action-level logging, and an interruption path.
What good looks like: The agent can only progress when the policy engine, approval flow, or containment boundary agrees with the specific action being attempted, and every meaningful step is attributable after the fact.
Practitioner takeaway: The governance unit for a Foundry agent is not the release, it is the action, and the safest control model is the one that can still intervene while the agent is deciding.