Skip to main content
The egisai SDK governs every supported LLM call without changing your calling convention. Once egisai.init() runs, supported provider SDKs are patched in place and each call goes through the same lifecycle.

​
The call path

1

Your code calls the provider

Your code makes an ordinary call — client.chat.completions.create(...), client.messages.create(...), model.generate_content(...), etc. There are no wrapper objects to remember.
2

Request evaluation

Before the upstream model runs, the SDK applies your organization’s active request-phase policies (cached locally and refreshed continuously). Rules such as PII detection, regex denylists, model allowlists, prompt-size caps, and intent-oriented checks for the prompt fall in this phase. See Policies and Two-phase governance.
3

A request verdict is computed

Each call resolves to one of three outcomes:
  • Allow — forwarded to the provider as-is.
  • Sanitize — sensitive values are masked locally, then the cleaned payload is forwarded.
  • Block — the call is refused. Depending on configuration the SDK raises PermissionError or returns a framework-shaped refusal object.
See Verdicts for the full picture.
4

The provider call runs (or doesn't)

On allow or sanitize the patched method delegates to the original provider SDK using the (possibly cleaned) payload. Blocked calls never reach the provider, so response evaluation is skipped.
5

Response evaluation

When the model responds, response-phase policies run against the assistant’s text, tool invocations, and connector targets. A blocked response is suppressed before it reaches your code, exactly the same way a blocked prompt would be.
6

An audit event is emitted

A structured event describing both phases, the matched rules, latency, and usage is delivered asynchronously so it never sits on the critical path of your model call. The audit row carries each phase’s decision independently — prompt_decision and response_decision — so the dashboard can show which side fired and which rules matched.

​
Two-phase evaluation

Each governed call is evaluated in two phases — once before the model runs and once after it returns — so policies can intervene on either side independently.

Request phase

Runs against the prompt before the provider is called. Local deterministic checks (PII patterns, regex denylists, prompt-size caps, model allow-lists) run first; LLM-backed intent checks run only after, and only on a sanitized copy if a deterministic rule asked for one. Raw prompt content never leaves your environment as part of these checks.

Response phase

Runs against the model response — assistant text, tool invocations, shell commands, and connector targets. If the response is blocked, the SDK suppresses it before it reaches your code, the same way a blocked prompt would be.
If the request phase blocks the call, the model is never invoked and the response phase is skipped. The audit event records prompt_decision only in that case; response_decision is left null.
See Two-phase governance for the full phase × rule-type matrix and how to choose the right phase for a rule.

​
What is governed

The SDK governs supported direct provider SDKs and the major agent frameworks in-process:
  • Direct provider SDKs. openai (Chat Completions, Responses API, streaming), anthropic (Messages API, streaming, tool use), google-genai and google-generativeai (generate_content, async, streaming, function calls), and boto3 for AWS Bedrock Converse + Bedrock Agents.
  • Agent frameworks. openai-agents, claude-agent-sdk, langchain (classic + 1.x), langgraph, crewai, autogen, agno, strands-agents, smolagents, llama-index, pydantic-ai, google-adk.
  • HTTP fallback. httpx / requests — optional broad capture for libraries that bypass the official provider SDKs. Matches on known provider hosts AND known model-call path tokens to avoid logging unrelated traffic.
Only frameworks actually importable in your environment are patched at runtime — uninstalled frameworks are silently skipped. See Integrations for the per-provider walkthrough. For tier-2 agent frameworks (LangGraph, CrewAI, AutoGen, …), the patch wraps the framework’s entry point for identity attribution and lets policy enforcement cascade to the inner provider patch. For the claude-agent-sdk specifically, PreToolUse + PostToolUse hooks gate tool dispatch and tool results inside the SDK process — see Claude Agent SDK.

​
Steady-state cost

After the first call for a given identity, local rules (PII, regex, size caps, model allow-lists) are a dictionary lookup — a fraction of a millisecond after warm-up. Intent checks (semantic_guard) call the hosted control plane; that round-trip is network time, not CPU. See Where to run the SDK. Audit delivery is asynchronous; latency to EgisAI does not block your provider call.

​
Where to run the SDK

The hosted control plane — policy fetch, the intent judge, and audit ingest — runs in GCP us-west1 (Oregon). Dashboard Policy is processing time of the rules that ran: local CPU plus the judge model’s own compute. It does not include the hop from your process to Egis, the hop from Egis to the judge model, TLS connect, or time spent in the model’s queue. That number is the same whether the SDK runs on a laptop or next to the control plane, and it matches the inline gateway. Transit still depends on placement. Running egisai.init() in us-west1 (or nearby on the west coast) shortens the hop from your process to Egis and makes the call faster. It does not change the Policy number. A laptop or a region a continent away can add on the order of 150–200 ms of transit on each intent-judge round-trip compared with a process already in us-west1. That wait is real; it just is not what Policy reports. Local checks (PII, regex) do not pay this hop.

​
Failure modes

The SDK is built to fail open on availability and fail closed on PII. For your specific deployment’s behavior, see your contract and the SECURITY document.

​
What’s next

Verdicts

Allow, sanitize, and block — what each one means in detail.

Agents

How the SDK identifies which agent made each call.

Policies

Categories of rules and where they’re configured.

Blocking behavior

Choose between raise and stub modes.