ValGuard vs OpenAI Agents SDK guardrails: in-process vs shared gate

Keep free SDK-native guardrails for one Python service. Add ValGuard when policy, shadow mode, and audit must span clients.

Last verified:

The OpenAI Agents SDK ships free, in-process guardrails for agents you build on that SDK. ValGuard is a vendor-neutral OpenAI-compatible validation proxy with shared rule packs, shadow mode, and audit rows. Use both when you want SDK ergonomics and an org-wide enforcement boundary.

Quick answer

Choose OpenAI Agents SDK guardrails when one Python codebase owns the agent path and in-process checks are enough. Choose ValGuard when several services or languages must share policy, you need shadow → enforce without redeploying app code, auditors want rule IDs on every evaluation, or playbooks gate multi-step handoffs. Keep the SDK for tools and turns either way. Point its OpenAI client at ValGuard when you want the network gate. See ValGuard + OpenAI Agents SDK.

Verdict

SDK-native guardrails fit a single Agents SDK service you control end to end. ValGuard fits multi-service policy, packaged domain packs, and audit evidence without building that control plane yourself. They are not mutually exclusive.

What each is built for

OpenAI Agents SDK owns agent loops, tools, handoffs, and optional in-process input/output guardrails tied to that runtime.

ValGuard sits on the OpenAI-compatible path. Deterministic rules run on every completion before the next model, tool, or customer-facing action. Playbooks add a light step graph so rules apply at handoffs. It is not a general workflow engine.

Comparison table

CapabilityAgents SDK guardrailsValGuardWho wins
Form factorIn-process Python SDKHosted OpenAI-compatible proxy (+ Enterprise self-host)SDK for one process; ValGuard for shared policy
Cost of guardrailsIncluded with the SDKValGuard planSDK when in-process is enough
Vendor neutralityOpenAI Agents ecosystemAny OpenAI-compatible clientValGuard for non-SDK services
Shadow → enforceBuild logging and rollout yourselfPer-agent setting on every planValGuard
Audit with rule IDsDepends on your loggingPer-rule evaluation rowsValGuard when auditors need named evidence
Domain packs (IDs, invoice math, leak patterns)Custom codeBuilt-in packsValGuard
Orchestration handoffsSDK handoffsPlaybooks with validation-gated routingDepends on graph needs
Zero extra network hopYes (in-process)NoSDK

Where ValGuard is stronger

  • Same rule IDs whether the client is Agents SDK, Node, or an n8n HTTP node.
  • Shadow mode without redeploying the agent service.
  • Domain and compliance packs you do not rewrite per language.
  • Playbooks that block, re-ask, or escalate at handoffs with measured overhead in benchmarks.

Where OpenAI Agents SDK guardrails are stronger

  • No vendor hop and no hosted dependency for checks that stay in one process.
  • Tight loop with tools and handoffs you already wrote in the SDK.
  • Free with the SDK when in-process policy is enough.

Cost and latency

SDK guardrails add CPU in your process. ValGuard engine packs are microseconds. HTTP path about 0.36 ms p50 with a mocked upstream. Model time is hundreds of milliseconds. Block/re-ask buffers the stream. See methodology.

Failure example

An agent proposes issue_refund with a schema-valid argument object. The SDK shape check passes. The amount exceeds the captured charge. Without a shared network gate, a second service that calls the same model can skip your in-process wrapper. With ValGuard on the path, a cross-field refund rule fails with a named rule ID before the tool runs.

Code

Point the SDK client at ValGuard (full wiring on the integration page):

import os
from openai import AsyncOpenAI
from agents import set_default_openai_client, set_default_openai_api

client = AsyncOpenAI(
    base_url="https://api.valguard.ai/v1",
    api_key=os.environ["VG_API_KEY"],
    default_headers={"X-VG-Agent": "support-triage"},
)
set_default_openai_client(client, use_for_tracing=False)
set_default_openai_api("chat_completions")

Keep SDK-native guardrails for checks that must stay local. Put shared business rules on the ValGuard agent.

Choose OpenAI Agents SDK guardrails if

  • One Python Agents SDK service owns the path
  • You accept rewriting policy when you add Node or a canvas
  • A network hop is unacceptable for that path

Choose ValGuard if

  • Several clients must share the same packs
  • You need shadow → enforce and rule IDs out of the box
  • You want playbooks or OpenAI-compatible canvas integrations

Using both

Keep SDK tools and handoffs. Put ValGuard on the chat-completions path for org policy. Avoid duplicate retries: assign each failure action to one owner.

Objections

  1. Why pay if the SDK is free? Pay when policy must span services or you need packaged shadow and audit.
  2. Latency. Quote engine µs, proxy ms, and model ms together. Streaming caveat applies to block/re-ask.
  3. If ValGuard is down. The call fails; we do not silently skip rules. Trust.
  4. Data residency. SaaS by default; Enterprise self-host for VPC. No free local runtime.
  5. False positives. Shadow first.
  6. Misses. No rule signature means no catch; side effects off-path are out of scope.

FAQ

Do you replace the Agents SDK? No. Keep the SDK for agents and tools.

Are SDK guardrails enough alone? Often for one service. Rarely for org-wide packs.

Where is the how-to? ValGuard + OpenAI Agents SDK.

Related

Next step

Quickstart or the Agents SDK integration.