Problem
Microsoft Agent Framework provides FIDES information-flow controls for enforcing integrity and confidentiality policies on locally invoked function tools.
However, the Python CodeAct integrations (Monty and Hyperlight) can invoke registered host tools through a lower-level callback path rather than the standard function-middleware pipeline. As documented in the existing implementation, nested host-tool invocations through this path do not receive FIDES per-tool policy enforcement.
PR #9175 introduced registration-time warnings and documentation describing this unsupported integration. That is an important improvement, but the warnings are advisory and do not prevent execution.
This presents a deployment limitation for applications that require mandatory security-policy enforcement:
- An application can configure FIDES policies for sensitive tools while using a CodeAct execution path that does not enforce those policies on nested host-tool calls.
- A warning is insufficient for environments where execution must stop when the required policy-enforcement boundary is unavailable.
- Existing guidance does not provide an explicit fail-closed contract that an application can require for CodeAct host-tool execution.
- Tool registration and run-scoped tool snapshots introduce additional points where security requirements must remain consistent.
This affects developers building enterprise agents that use generated code to orchestrate sensitive host tools, including tools for accessing internal APIs, customer records, financial workflows, or protected resources.
The request concerns enforcing a documented security configuration requirement. It is not a report of a confirmed vulnerability or a claim that the existing CodeAct integrations promise FIDES protection.
Use Case and Evidence
Enterprise CodeAct agent with sensitive host tools
Consider an enterprise AI agent that uses Monty or Hyperlight to execute model-generated Python code and exposes registered host functions for:
- Reading customer records
- Updating internal business systems
- Accessing confidential documents
- Making authenticated API requests
The application requires FIDES integrity and confidentiality controls for these functions.
For direct function invocation, the application's configured FIDES middleware can evaluate security policies before tool execution.
For nested host-tool calls originating from CodeAct-generated code, the existing integration uses a different execution path and does not provide equivalent FIDES middleware enforcement.
This creates a practical difficulty: the developer cannot require an explicit runtime guarantee that all CodeAct host-tool executions subject to FIDES requirements will be mediated or rejected.
Repository evidence
PR #9175 — Python: Warn about unsupported FIDES CodeAct tools
#9175
This merged PR documents the compatibility limitation and introduces warnings when recognized FIDES metadata is encountered. The PR explicitly preserves existing invocation behavior.
Relevant implementation areas:
python/packages/monty/agent_framework_monty/_execute_code_tool.pypython/packages/hyperlight/agent_framework_hyperlight/_execute_code_tool.pypython/packages/core/agent_framework/security.py
The existing Monty, Hyperlight and FIDES documentation also describes the limitation.
Why current behavior is insufficient
For a security-sensitive deployment, discovering an unsupported enforcement path through a log warning is not equivalent to preventing unauthorized execution.
The desired guarantee is simple:
When an application explicitly requires FIDES enforcement for CodeAct host tools, unsupported execution paths must not silently proceed.
A narrowly scoped fail-closed behavior would let applications make this requirement explicit and testable.
No exploitation or production incident is claimed. The motivation is the documented enforcement limitation and its implications for mandatory security configurations.
Desired Outcome
Provide an opt-in capability allowing Python applications to require security-policy coverage for CodeAct host-tool execution.
A successful outcome should allow developers to:
- Explicitly require FIDES-compatible enforcement for registered CodeAct host tools.
- Prevent host-tool execution when the requested enforcement guarantee cannot be provided.
- Receive a clear, actionable error identifying the unsupported security-enforcement boundary.
- Apply the requirement consistently to initially registered tools, dynamically added tools, and run-scoped tool snapshots.
- Preserve current behavior for applications that do not enable the strict security requirement.
- Reliably test that denied executions produce no host-tool side effects.
The feature should not imply that sandbox isolation, outer execute_code approval, or registration-time warnings provide per-host-tool FIDES enforcement.
The objective is to prevent an application from unintentionally proceeding with a sensitive CodeAct execution when its explicitly configured security requirement is unsupported.
Alternatives Considered
1. Use existing FIDES registration-time warnings
PR #9175 provides diagnostics for recognized security metadata.
Limitation: Warnings do not prevent execution and may be insufficient when policy enforcement is mandatory. Metadata-based warnings also cannot establish complete enforcement coverage for every possible tool configuration.
2. Avoid CodeAct for security-sensitive tools
Applications can register sensitive operations as ordinary function tools and route them through their existing FIDES middleware configuration.
Limitation: This prevents applications from using CodeAct-based orchestration for workflows involving those operations. It is a valid current workaround but does not provide a strict enforcement mode for CodeAct integrations themselves.
3. Require approval for the outer execute_code operation
Applications can use existing approval mechanisms to authorize a generated-code execution request.
Limitation: Approval of the outer execution does not establish that every nested host-tool invocation receives the intended FIDES integrity and confidentiality checks.
4. Implement application-specific host-tool wrappers
Developers can add authorization checks inside individual host functions.
Limitation: This distributes policy enforcement across application code and does not automatically reproduce FIDES context-label propagation or information-flow semantics.
These approaches remain useful. The proposed feature would add an explicit, optional enforcement guarantee for deployments where advisory compatibility warnings are insufficient.
Proposed Direction
I suggest initially considering a narrowly scoped, opt-in strict-security requirement on the Python CodeAct integrations.
The public API shape should be determined with maintainers.
Conceptually, when strict coverage is enabled:
- Before an unsupported host-tool execution occurs, the runtime checks whether the required security-enforcement path is available.
- If enforcement cannot be guaranteed, execution is rejected before the host function runs.
- The requirement comes from trusted application configuration, not model-generated code or arguments.
- Dynamic tool registration and run-scoped configuration cannot weaken the requirement.
- The runtime provides a clear failure reason without exposing sensitive tool arguments.
- Without strict coverage enabled, existing behavior remains unchanged.
The initial implementation does not need to reproduce the entire FIDES middleware inside Monty or Hyperlight.
A first phase could provide a reliable fail-closed barrier for unsupported host-tool execution. A future phase could explore supporting actual per-host-tool FIDES mediation if maintainers consider that architecture appropriate.
I would welcome maintainer guidance on whether this belongs in the CodeAct provider configuration, a shared security-capability contract, or another existing extension point.
Scope and Non-Goals
In scope
- Python Monty and Hyperlight CodeAct integrations
- Opt-in fail-closed handling of unsupported FIDES coverage
- Enforcement consistency across initial and dynamic tool registration
- Run-scoped tool configuration and execution checks
- Deterministic tests verifying rejection before host-tool side effects
- Clear compatibility documentation and an example demonstrating strict versus existing behavior
Non-goals
- Replacing or redesigning FIDES
- Introducing a separate agent security framework
- Claiming complete prompt-injection prevention
- Automatically enabling strict behavior for existing applications
- Changing the existing security guarantees of Monty or Hyperlight sandboxes
- Automatically propagating all middleware into generated-code callbacks
- Changing remote/provider-hosted tool execution
- Implementing the same feature in .NET as part of the initial contribution
The goal is a small, backward-compatible security capability focused on making an existing enforcement limitation explicitly controllable by application developers.
Language
Python
Contribution Intent
I am willing to implement this
Acknowledgements
Problem
Microsoft Agent Framework provides FIDES information-flow controls for enforcing integrity and confidentiality policies on locally invoked function tools.
However, the Python CodeAct integrations (Monty and Hyperlight) can invoke registered host tools through a lower-level callback path rather than the standard function-middleware pipeline. As documented in the existing implementation, nested host-tool invocations through this path do not receive FIDES per-tool policy enforcement.
PR #9175 introduced registration-time warnings and documentation describing this unsupported integration. That is an important improvement, but the warnings are advisory and do not prevent execution.
This presents a deployment limitation for applications that require mandatory security-policy enforcement:
This affects developers building enterprise agents that use generated code to orchestrate sensitive host tools, including tools for accessing internal APIs, customer records, financial workflows, or protected resources.
The request concerns enforcing a documented security configuration requirement. It is not a report of a confirmed vulnerability or a claim that the existing CodeAct integrations promise FIDES protection.
Use Case and Evidence
Enterprise CodeAct agent with sensitive host tools
Consider an enterprise AI agent that uses Monty or Hyperlight to execute model-generated Python code and exposes registered host functions for:
The application requires FIDES integrity and confidentiality controls for these functions.
For direct function invocation, the application's configured FIDES middleware can evaluate security policies before tool execution.
For nested host-tool calls originating from CodeAct-generated code, the existing integration uses a different execution path and does not provide equivalent FIDES middleware enforcement.
This creates a practical difficulty: the developer cannot require an explicit runtime guarantee that all CodeAct host-tool executions subject to FIDES requirements will be mediated or rejected.
Repository evidence
PR #9175 — Python: Warn about unsupported FIDES CodeAct tools
#9175
This merged PR documents the compatibility limitation and introduces warnings when recognized FIDES metadata is encountered. The PR explicitly preserves existing invocation behavior.
Relevant implementation areas:
python/packages/monty/agent_framework_monty/_execute_code_tool.pypython/packages/hyperlight/agent_framework_hyperlight/_execute_code_tool.pypython/packages/core/agent_framework/security.pyThe existing Monty, Hyperlight and FIDES documentation also describes the limitation.
Why current behavior is insufficient
For a security-sensitive deployment, discovering an unsupported enforcement path through a log warning is not equivalent to preventing unauthorized execution.
The desired guarantee is simple:
When an application explicitly requires FIDES enforcement for CodeAct host tools, unsupported execution paths must not silently proceed.
A narrowly scoped fail-closed behavior would let applications make this requirement explicit and testable.
No exploitation or production incident is claimed. The motivation is the documented enforcement limitation and its implications for mandatory security configurations.
Desired Outcome
Provide an opt-in capability allowing Python applications to require security-policy coverage for CodeAct host-tool execution.
A successful outcome should allow developers to:
The feature should not imply that sandbox isolation, outer
execute_codeapproval, or registration-time warnings provide per-host-tool FIDES enforcement.The objective is to prevent an application from unintentionally proceeding with a sensitive CodeAct execution when its explicitly configured security requirement is unsupported.
Alternatives Considered
1. Use existing FIDES registration-time warnings
PR #9175 provides diagnostics for recognized security metadata.
Limitation: Warnings do not prevent execution and may be insufficient when policy enforcement is mandatory. Metadata-based warnings also cannot establish complete enforcement coverage for every possible tool configuration.
2. Avoid CodeAct for security-sensitive tools
Applications can register sensitive operations as ordinary function tools and route them through their existing FIDES middleware configuration.
Limitation: This prevents applications from using CodeAct-based orchestration for workflows involving those operations. It is a valid current workaround but does not provide a strict enforcement mode for CodeAct integrations themselves.
3. Require approval for the outer
execute_codeoperationApplications can use existing approval mechanisms to authorize a generated-code execution request.
Limitation: Approval of the outer execution does not establish that every nested host-tool invocation receives the intended FIDES integrity and confidentiality checks.
4. Implement application-specific host-tool wrappers
Developers can add authorization checks inside individual host functions.
Limitation: This distributes policy enforcement across application code and does not automatically reproduce FIDES context-label propagation or information-flow semantics.
These approaches remain useful. The proposed feature would add an explicit, optional enforcement guarantee for deployments where advisory compatibility warnings are insufficient.
Proposed Direction
I suggest initially considering a narrowly scoped, opt-in strict-security requirement on the Python CodeAct integrations.
The public API shape should be determined with maintainers.
Conceptually, when strict coverage is enabled:
The initial implementation does not need to reproduce the entire FIDES middleware inside Monty or Hyperlight.
A first phase could provide a reliable fail-closed barrier for unsupported host-tool execution. A future phase could explore supporting actual per-host-tool FIDES mediation if maintainers consider that architecture appropriate.
I would welcome maintainer guidance on whether this belongs in the CodeAct provider configuration, a shared security-capability contract, or another existing extension point.
Scope and Non-Goals
In scope
Non-goals
The goal is a small, backward-compatible security capability focused on making an existing enforcement limitation explicitly controllable by application developers.
Language
Python
Contribution Intent
I am willing to implement this
Acknowledgements