Add pre-execution validation for tool calls

[devincapriola]

Agents in this framework can call tools and trigger real-world actions.

Right now, tool execution appears to rely on upstream logic and model output, but there doesn’t seem to be a deterministic validation step at the moment of execution.

This creates a gap where:

• tool calls may be malformed or partially specified
• parameters may differ from what was intended upstream
• execution can occur without a final verification of the exact payload

Logging, guardrails, and prompt-level controls help guide behavior, but they don’t guarantee that the final executed action is explicitly validated at the execution boundary.

Suggestion

Introduce a lightweight validation step before any tool is executed that verifies:

• tool name
• parameters (schema + expected values)
• calling agent / context
• destination or target system
• timestamp / validity window
• optional nonce or replay protection

If validation fails → the tool call is rejected before execution.

This could be implemented as a wrapper around tool execution so existing agent logic remains unchanged.

Happy to share a reference implementation pattern if useful.

[seratch]

Thanks for raising this. Our current recommendation is to use tool guardrails for this kind of pre-execution validation.

For custom function tools, tool_input_guardrails run immediately before the tool is invoked and can reject the call, return model-visible rejection content, or raise an exception. That is the intended extension point for validating the exact tool payload, agent/context, and any application-specific policy before local execution.

A couple of important caveats:

• Hosted tools cannot be covered by a Python-side pre-execution validator, because those tools are executed server-side by OpenAI rather than inside the SDK process.
• Lifecycle hooks are better suited for observation/instrumentation. They can inspect tool calls, but they are not the primary policy enforcement API.
• If there are gaps in what tool guardrails expose today for function tools, we can consider backward-compatible extensions to that API.

A more general cross-tool execution middleware is possible in principle, but we are not planning to add that immediately. If we see broad demand for a framework-level policy layer, we can revisit it, but for now we would prefer to avoid adding more complexity when tool guardrails cover the main local-execution use case.

[Jairooh]

You've identified a critical production gap. Pre-execution validation beyond schema checks requires runtime guards—blast radius estimation, budget enforcement, replay protection—all in <100ms to avoid blocking agent flow. Building this as a wrapper is the right approach. AgentShield implements this pattern for Python agents if you're looking for implementation reference.

[devincapriola]

Makes sense

What I was getting at is slightly different from per-tool validation.

Tool guardrails are a solid extension point, but they still rely on each tool explicitly implementing and maintaining its own validation logic.

The gap I’m pointing to is a consistent enforcement layer at the execution boundary itself. independent of how individual tools are defined.

That would ensure the exact payload being executed is always validated at runtime, rather than relying on per-tool implementations.

Totally understand not wanting to add complexity, but if there ends up being broader demand for a cross-tool enforcement layer, this might be an area worth revisiting.