Pydantic AI for Enterprise
Pydantic AI is an open-source Python agent framework from Pydantic, the company behind the Pydantic validation library, with commercial enterprise support from Pydantic. Agents run in your own process against the models you choose, from Azure OpenAI, Amazon Bedrock and Google Vertex AI to models you host yourself, and the library sends no usage telemetry.
Around the open-source framework, Pydantic offers optional commercial services: Pydantic Logfire for tracing, evals and cost tracking, the Pydantic AI Gateway, part of Logfire, for one controlled entry point to the supported model providers, and enterprise support. Pydantic AI works without any of them, and support for the framework does not require Logfire. Logfire and the Gateway run in Pydantic’s cloud or in your own Kubernetes cluster. Pydantic Enterprise describes the plans.
This page answers the questions security, platform and procurement teams ask before adopting it, each with the short answer and a link to the page that covers it in full. Going to Production covers the engineering side: crash recovery, cost limits, testing and deployment.
| Your team wants to know… | Short answer |
|---|---|
| What leaves our infrastructure? | The model requests, tool calls and trace exports you configure; no usage telemetry and no Pydantic-hosted runtime |
| Can we run on-prem or air-gapped models? | Yes: Ollama, vLLM or any OpenAI-compatible server you run |
| Can we use our cloud’s models? | Azure OpenAI and Microsoft Foundry, Amazon Bedrock and Google Vertex AI, selected by the model string |
| How do we control model access and spend? | The Pydantic AI Gateway: one key per team or service, spending caps, provider failover, every request traced |
| How do we keep a person in control? | Tool approval, guardrails, and a sandbox for model-written code |
| Can we audit what an agent did? | With instrumentation on, every run, model request and tool call as an OpenTelemetry trace, in Logfire or your own backend |
| How do we know quality holds in production? | Pydantic Evals on datasets before a release and on live traffic after it, with results in Logfire |
| Which compliance certifications apply? | The library runs in your process; for Logfire and the Gateway, see the Pydantic Trust Center |
| How do we standardize across teams? | Agent specs, shared capabilities, Pydantic AI Harness and Gateway policies |
| Who do we call when it breaks? | Pydantic AI engineers, under a commercial agreement with an SLA |
Pydantic AI, Pydantic AI Harness, Pydantic Evals and Pydantic Graph are Python packages that run in your own process: there is no Pydantic-hosted agent runtime. The library sends no usage telemetry; it connects to the model providers, MCP servers and tools you configure.
- Durable execution runs on an engine you operate, such as Temporal, DBOS or Prefect, or on that engine’s own cloud.
- Traces go where you send them. Pydantic Logfire is optional, and runs in Pydantic’s cloud in a US or EU region, as a single-tenant Enterprise Dedicated deployment in any GCP region with customer-managed encryption keys, or self-hosted on your own Kubernetes cluster so telemetry stays in your infrastructure; any OpenTelemetry backend works instead. Logfire’s SDK scrubs likely-sensitive values such as tokens and passwords, but not prompt and response content;
include_content=Falsekeeps prompts, completions and tool arguments out of the spans. - The Pydantic AI Gateway is optional: model requests pass through it to the provider in the provider’s own format. It runs on Logfire Cloud in the same US or EU region as your Logfire organization, or on self-hosted Logfire. Calling providers directly works without it.
- Model prices for cost estimates ship with each release;
update_in_background()downloads newer ones only when you call it.
Yes. Point an agent at a model server inside your network and model requests stay there; for a whole run to stay inside, its tools, MCP servers and trace exporter must be inside too:
- Ollama on your own servers, with the
ollama:prefix; - vLLM, with the
vllm:prefix; - any other OpenAI-compatible server through
OpenAICompatibleProvider, as Other endpoints explains, or any other API through a custom model.
For an air-gapped deployment, install the packages from your own package mirror and point agents at a model server inside the network. A few optional integrations download files on first use, such as tiktoken encodings and Sentence Transformers models; mirror those too.
Pydantic AI runs on Azure OpenAI and Microsoft Foundry, Amazon Bedrock and Google Vertex AI, authenticating with that cloud’s own credentials. Switching an agent between them, or to OpenAI, Anthropic, Gemini or a local model, means changing one string, without rewriting the agent, for the features both providers support. Models and Providers lists every supported service, and a fallback model moves to another provider when one is down.
Without extra infrastructure, each provider reads its key from an environment variable or your secret manager, and SpendLimits (Harness) refuses new requests once a per-tenant, daily or monthly budget is spent; its page explains when spend can overshoot and how to share budgets across processes. When many teams call models, the Pydantic AI Gateway moves that control to one place:
- One key for many providers: an application holds one Gateway key for OpenAI, Anthropic, Google Vertex AI, Groq and Amazon Bedrock models, and selects a model with a
gateway/model string. Use your own provider keys (BYOK) at no markup, or pay for inference through Pydantic at the markup on the pricing page. - Spending caps: daily, weekly and monthly limits per project, user and API key, checked before a request is forwarded to the provider, so you can issue one key per service or environment.
- Failover and load balancing: gateway endpoints route a model across providers by priority and weight, and fall back to the next provider on retryable errors.
- A record of every request: with Gateway telemetry on, every request becomes a span in Logfire with the model, token counts, cost and timing, nested in your agent’s trace, since Pydantic AI’s
gateway/provider sends the trace headers. Prompts and responses are recorded only when the project’s Include messages setting is on. - Data protection: Gateway guardrails (in Beta) detect secrets and personal data in requests and can flag, redact or block them before they are forwarded.
- Access: the Gateway uses Logfire’s organizations and roles: admins manage providers, endpoints and spending, and members create their own keys. On the Enterprise plan that includes SSO with your identity provider.
- Approval: mark a tool
requires_approval=Trueand the run ends with the pending call; your application stores the conversation, and the run resumes, days later if need be, once a person approves or denies the call. Going to Production shows the full flow, andToolCallJudge(Harness) replaces the person with an automated check by a second model. - Guardrails: guardrails (Harness) check the prompt, each tool call and result, and the final output, and can block, redact secrets and PII, or ask for approval. The prompt injection defender screens tool results. The Gateway’s guardrails apply a second check on the traffic path, for every application that uses the Gateway.
- Least privilege: give each caller only the tools it may use, and run model-written code in a sandbox; How do I limit what the agent can touch? covers both.
With instrumentation turned on, Pydantic AI records every run, model request and tool call as an OpenTelemetry trace, following the GenAI semantic conventions, with token usage and estimated cost. Send the traces to the OpenTelemetry backend you already run, or to Logfire, which shows agent runs next to the HTTP requests, database queries and background jobs around them, and lets you query every span with SQL, for example to total token usage and cost per agent or model. Retention is set in the backend you choose; Logfire’s Enterprise plan has custom retention. Traces record what agents did; changes to keys, roles and policies are recorded by the systems that manage them. The message history of each run is plain data you can store next to the trace.
Pydantic Evals runs an agent against a dataset of cases with scoring rules you write in code, so a prompt or model change can be checked before release, including in CI. Online evaluation scores live traffic, every call or a sample, in the background and records the scores as OpenTelemetry events. With Logfire, experiment results and online scores sit next to the traces they came from, and you can compare runs to see what changed. Pydantic Evals is open source and works without Logfire.
Pydantic AI, Harness, Evals and Graph run in your environment, under the security controls you apply to the rest of your application; the library holds no certifications of its own. For Logfire and the Gateway, the Pydantic Trust Center has the certifications and reports, and Logfire for platform and security teams covers regions, scrubbing and self-hosting.
- Agent specs keep an agent’s model, instructions and capabilities in a YAML or JSON file, so its configuration is reviewed and versioned apart from application code.
- Capabilities bundle tools, instructions, hooks and model settings into one reusable unit: a platform team writes the company’s policies once and every team’s agents can reuse them.
- Pydantic AI Harness provides ready-made capabilities, such as guardrails, spend limits per tenant or month, and managed prompts, which are versioned in Logfire and rolled out without a redeploy.
- The Gateway gives every application that routes through it the same model access, spending caps per project, user and API key, and failover rules, set once by an admin instead of in each application.
- Logfire gives every team’s agents one place for traces, costs and evals; on the Enterprise plan with SSO, SCIM group provisioning and custom roles.
Enterprise support gives your team direct access to Pydantic AI engineers, with an SLA defined in your agreement; that page lists what it covers. It is its own agreement, separate from Logfire support: it does not require a Logfire or Gateway subscription, and a Logfire plan, at any tier, does not include it. Logfire’s Enterprise plans include their own support for Logfire and the Gateway. Pydantic AI follows a version policy, vulnerabilities are reported through its security policy, and the docs, issue tracker and community help stay open to everyone. Open-source projects that run on it are listed on Built with Pydantic AI.