Add deterministic validation at execution boundary for agent actions

[devincapriola]

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.

[chetantoshniwal]

Can you clarify with your concrete scenario on what exactly you are proposing and how it will be generic.

[devincapriola]

Example scenario

An agent is orchestrating a workflow to trigger a payment API:

1. Agent A determines an action → “send payment”
2. Parameters are built across steps (amount, destination, metadata)
3. Another agent or step modifies or enriches those parameters
4. Final API call is executed

At each step, validation may occur, but the final payload being executed is still assembled at runtime.

The gap

Even if:

• schema validation passes
• policies are applied upstream
• guardrails are in place

There isn’t necessarily a single deterministic check right before execution that verifies:

• the exact action
• final parameters
• destination
• execution context

What I’m proposing

A generic validation layer at the execution boundary, regardless of the specific tool or API.

Conceptually:

Where validate(...) can include:

• schema + expected value checks
• permission/policy checks
• environment or tenant constraints
• replay protection or validity window

Why this is generic

This pattern applies across:

• API calls (payments, emails, data writes)
• tool execution
• code execution
• multi-agent workflows

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]

@devincapriola the execution boundary you're describing is already enforced. For tool/function execution, FunctionMiddleware runs right before the tool fires, receives the validated arguments and function metadata via FunctionInvocationContext, and can abort by raising MiddlewareTermination. AgentMiddleware and ChatMiddleware cover 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]

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:

• FunctionMiddleware for tool/function calls
• AgentMiddleware / ChatMiddleware for agent and chat boundaries
• receiving executor handlers for custom workflow payload validation

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.