EVE + OpenAI Python Client

Compatibility: Experimental integration — structurally implemented but not included in the supported release-candidate adapter matrix.

This page covers governing tool calls made by an application that uses the OpenAI Python client directly (the API client, not the OpenAI Agents SDK — see openai-agents.md for that). The OpenAI Python client was present during release-candidate validation and its interception path is recorded, but this adapter is a wrapper-enforced integration and is not part of the supported adapter matrix. Only the generic adapter is SUPPORTED.

How governance works here

When your app decides to execute a tool that the model requested, you route that execution through EVE first. CoreGuard makes a deterministic ALLOW / BLOCK / MODIFY decision before the tool runs, with no LLM in the decision path, and can produce a signed evidence record.

from eve_coreguard import EVE

eve = EVE()  # hosted endpoint

# You have a tool call the model asked for; govern it before executing.
decision = eve.govern_tool_call(
    tool="lookup_customer",
    arguments={"email": "user@example.test"},
    context={
        "tenant_id": "tenant_demo",
        "principal_id": "assistant_main",
        "session_id": "sess_88c1",
    },
)

# govern_tool_call returns a plain dict (allowed / action / reason_codes / certificate / ...).
if decision["action"] == "BLOCK":
    tool_output = {"error": "blocked_by_policy", "reason_codes": decision["reason_codes"]}
else:
    tool_output = lookup_customer(email="user@example.test")

The eve-coreguard Python package (0.2.2) is distributed privately during a pilot; it is not published to a public index. The primary entry point is from eve_coreguard import EVE.

Hardened alternative

A wrapper only governs the call sites you route through it. A code path that calls the underlying tool directly is not intercepted. For an enforcement boundary a direct call cannot route around, choose one of:

• A restricted server-side tool registry: the model-facing app never holds direct tool functions; tools are only reachable through the governed server path.
• A sidecar through which tool execution is proxied, so governance runs out-of-process.
• Network enforcement so tool endpoints are only reachable via the governed path.

Readiness

• This adapter: experimental (wrapper-enforced; not in the supported release-candidate adapter matrix).
• Generic Python adapter: SUPPORTED — use it directly if you control the tool call site.
• EVE SDK core: RELEASE CANDIDATE WITH EXCLUSIONS.

Limitations

• Wrapper-enforced integration: bypassable by a direct call to the underlying tool. Hard enforcement requires a gateway/sidecar or a restricted server-side tool registry.
• The OpenAI Agents SDK is a distinct integration and was not validated against a pinned live version — see openai-agents.md.
• The pip client governs via hosted mode and needs a reachable endpoint; embedded governance is the EVE service.
• Signed-evidence integrity is verifiable offline; independent verification needs the Ed25519 public key. Verification proves authenticity, not decision correctness.