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 CoreGuardClient

client = CoreGuardClient(api_key="eve_sk_...")

# You have a tool call the model asked for; govern it before executing.
result = client.evaluate(
    request_id="req-88c1",
    tenant_id="tenant_demo",
    proposed_action={"type": "lookup_customer", "email": "[email protected]"},
    model_output={"decision": "call_tool", "confidence": 0.9},
    context={"principal_id": "assistant_main", "session_id": "sess_88c1"},
    policy_set="pii_handling",
)

# evaluate returns an EvaluationResult (decision.status / decision.action / risk / ...).
if result.decision.status == "BLOCKED":
    tool_output = {"error": "blocked_by_policy", "action": result.decision.action}
else:
    tool_output = lookup_customer(email="[email protected]")

The eve-coreguard Python package (0.2.7) is published on public PyPI (pip install eve-coreguard). The primary entry point is the CoreGuardClient class.

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 ECDSA P-384 public key. Verification proves authenticity, not decision correctness.