Skip to main content
Verify AI agent outputs before execution. PyPI version Tests License

What is QWED Open Responses?

QWED Open Responses provides deterministic verification guards for AI agent outputs. It works with:
  • OpenAI Responses API
  • LangChain agents
  • LlamaIndex
  • Any AI framework
Use it when you need runtime tool call verification, AI safety guardrails, and policy enforcement before an agent executes an action.

The problem

When AI agents execute tools or generate structured outputs, they can:
  • 🔧 Call dangerous functions - rm -rf /, DROP TABLE
  • 🧮 Produce incorrect calculations - Financial errors, wrong totals
  • 📋 Violate business rules - Invalid state transitions
  • 🔐 Leak sensitive data - PII, API keys in responses
  • 💰 Exceed budgets - Unlimited API calls

The solution

QWED Open Responses intercepts and verifies every agent output before execution:

How it works


The 6 guards


Installation

Basic

With framework integrations


Quick start

Calling verify() with no guards configured fails closed. ResponseVerifier() without default_guards (or VerifiedOpenAI without guards) returns verified=False with the reason “No guards configured”, and blocks the response in strict mode. Earlier versions returned verified=True in this case. Constructing VerifiedOpenAI without guards also emits a UserWarning, because fail-closed verification would block every response. Always configure at least one guard.

Basic verification

Verify structured output

verify_structured_output requires a schema or at least one guard. Calling it with neither raises ValueError, because the call would verify nothing. An explicitly supplied empty schema {} is honored as a valid JSON Schema that matches anything.

Framework integration

LangChain

OpenAI SDK


Streaming middleware

The OpenResponsesMiddleware intercepts streaming events from the Open Responses protocol, verifying tool_call and function_call items through your guard stack before they are yielded to the consumer.

Usage

Parameters

How it works

  1. Non-tool items (text, metadata) pass through unchanged
  2. Items with type of tool_call or function_call are verified against all guards in their original shape, before the middleware yields them. The type match ignores case and surrounding whitespace, so " Function_Call " is verified as a function_call
  3. Tool-shaped items that can’t be verified unambiguously are blocked. This covers items with an unknown type, ambiguous envelopes, and tool calls nested inside other items
  4. tool_result and function_call_output items pass through; the middleware does not validate their correlation metadata. Results that hide a nested tool call are blocked
  5. If verification passes, the original item is yielded
  6. If verification fails and block_on_failure is True, a system_intervention item is yielded instead:
ArgumentGuard and TaxGuard checks also run on batched and nested tool calls inside a streamed item, not only on the top-level call.

Budget tracking across a stream

Pass a context to verify_stream to enforce SafetyGuard budget limits for the whole stream:
The middleware copies the context and adds each item’s reported usage.cost and usage.total_tokens to the running total_cost and total_tokens. Later tool calls are verified against those totals, so a call that arrives after the budget is spent is blocked. Your original context dictionary is not modified.

Stats methods


Why QWED Open Responses?

Security comparison

Real-world impact

  • Finance: Prevent wrong calculations in trading bots
  • Healthcare: Block PII leaks in patient summaries
  • E-commerce: Verify order totals before payment
  • DevOps: Prevent dangerous shell commands

Configuration

Environment variables

Custom guard configuration


Next steps