Repository navigation
Add deterministic validation at execution boundary for agent actions #5366
Description
The framework enables agents to orchestrate workflows and trigger real-world actions (tool calls, API requests, etc).
From the documentation and examples, it appears that developers are expected to implement their own safeguards and validation logic within the application layer.
This creates a potential gap at the moment of execution:
- actions may be constructed across multiple steps or agents
- parameters can evolve during orchestration
- execution may occur without a final, deterministic validation of the exact payload being committed
While upstream validation, policies, and guardrails are important, they do not guarantee that the final executed action is explicitly verified at the execution boundary.
Suggestion
Introduce a system-level validation step before execution that verifies:
- agent identity / context
- action being performed
- parameters (schema + expected values)
- destination or external system
- timestamp / validity window
- optional nonce or replay protection
If validation fails → execution does not occur.
This could be implemented as an execution wrapper or middleware layer, ensuring validation is consistently enforced across all agents and workflows rather than relying on individual implementations.
Happy to share a reference implementation pattern if useful.
Activity
chetantoshniwal commentedon Apr 21, 2026
Can you clarify with your concrete scenario on what exactly you are proposing and how it will be generic.
devincapriola commentedon Apr 23, 2026
Example scenario
An agent is orchestrating a workflow to trigger a payment API:
At each step, validation may occur, but the final payload being executed is still assembled at runtime.
The gap
Even if:
There isn’t necessarily a single deterministic check right before execution that verifies:
What I’m proposing
A generic validation layer at the execution boundary, regardless of the specific tool or API.
Conceptually:
Where
validate(...)can include:Why this is generic
This pattern applies across:
The key idea is having a consistent enforcement point right before execution, rather than relying on validation being distributed across earlier steps or individual components.
moonbox3 commentedon Apr 27, 2026
Devin Capriola (@devincapriola) the execution boundary you're describing is already enforced. For tool/function execution,
FunctionMiddlewareruns right before the tool fires, receives the validated arguments and function metadata viaFunctionInvocationContext, and can abort by raisingMiddlewareTermination.AgentMiddlewareandChatMiddlewarecover the agent-identity and chat-call boundaries. This applies inside workflows too - when an agent runs as an AgentExecutor, its full middleware stack still fires, so the boundary doesn't move.At the workflow level, edges enforce structural type compatibility (the receiver must declare a handler for the message type) but deliberately do not introspect payload contents. That's a threat-model decision: the runtime is a typed message bus, not a value-validator. Field-level / invariant / replay-protection checks belong either in the agent's
FunctionMiddleware(for tool calls) or in the receiving executor's handler (for custom executors) - both of which already give you a deterministic, single enforcement point right before execution.If you have a concrete scenario these don't cover, happy to look at it. See agent_framework/_middleware.py and the samples under python/samples/02-agents/middleware/for the existing patterns.
devincapriola commentedon Apr 27, 2026
If FunctionMiddleware can run immediately before the tool fires, receive the final validated arguments plus function metadata, and abort execution via MiddlewareTermination, then that does cover the execution-boundary pattern I was asking about for tool/function execution.
The distinction I was trying to clarify is mainly around whether this exists as a consistent enforcement model across all execution paths, including workflows and custom executors, not just standard function tools.
It sounds like your intended model is:
The remaining question I’d have is whether there is a recommended sample or pattern for implementing replay protection / validity windows / payload integrity checks consistently across those middleware and executor paths, so teams don’t reimplement that logic differently in each place.
Python: Samples: deterministic action-boundary validation middleware (m…
moonbox3 commentedon Sep 8, 2026
Existing middleware covers the boundary; the requested example merged in #6528.