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, every subsequent call is a dictionary lookup. The SDK is designed so that policy evaluation adds on the order of a fraction of a millisecond per call after warm-up. Audit delivery is asynchronous; latency to EgisAI does not block your provider call.

​
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.