The egisai SDK governs every supported LLM call without changing your calling convention. OnceDocumentation Index
Fetch the complete documentation index at: https://docs.egisai.co/llms.txt
Use this file to discover all available pages before exploring further.
egisai.init() runs, supported provider SDKs are patched in
place and each call goes through the same lifecycle.
The call path
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.The SDK applies your active policies
Before the upstream model runs, the SDK applies your organization’s active
policies (cached locally and refreshed continuously). Rules such as PII
detection, regex denylists, model allowlists, prompt-size caps, and
intent-oriented checks are evaluated in a fixed order defined by the
product. See Policies.
A 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
PermissionErroror returns a framework-shaped refusal object.
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.Two-phase evaluation
Policy evaluation happens in two clearly separated phases.Phase 1 — Local checks
Deterministic rules that run entirely inside your process. PII pattern
detection, regex denylists, prompt-size caps, and model allow-lists fall
in this phase. Raw prompt content never leaves your environment as part of
these checks.
Phase 2 — Intent checks
Rules that involve a judge are run only after Phase 1 finishes. If Phase 1
sanitized the prompt, Phase 2 sees the cleaned text — never the original
sensitive values.
If Phase 1 already blocks the call, Phase 2 is skipped entirely. The verdict
precedence across all matches is
block > sanitize > allow.What is governed
The SDK governs supported provider SDKs in-process:openai— Chat Completions, Responses API, streaming variants.anthropic— Messages API, streaming variants.google-generativeai—GenerativeModel.generate_content, streaming variants.httpx/requests— optional broad HTTP capture for libraries that don’t go through one of the official SDKs above.
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.| Situation | Behavior |
|---|---|
| Control plane unreachable at startup | The SDK runs in a degraded mode and logs a warning. Local checks remain in force where the engine can evaluate them. The user’s provider call still proceeds. |
| Local PII engine errors mid-evaluation | The call is treated as if PII was detected — better to over-block than to leak regulated values. |
| Audit delivery temporarily fails | Events are retried asynchronously; user-facing call latency is unaffected. |
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.