Pydantic AI Security for Pydantic AI Agents, MCP Tools, Guardrails and Human Approval

Pydantic AI's deferred tools are a clean design. Mark a tool requires_approval=True and the model's call becomes a pending request instead of an execution. The run ends with a DeferredToolRequests output listing each call with its validated arguments, you approve or deny each one, and you resume the run with a DeferredToolResults object. Denials can carry a message back to the model through ToolDenied. For approval that depends on the arguments, a tool can raise ApprovalRequired conditionally, and MCP servers can be wrapped so their tools require approval too.

Two details decide whether this is a control or a formality. First, it is opt-in: by default a Pydantic AI tool runs without any approval. Second, Pydantic's own documentation carries this warning, and it is the most important sentence on the page: "Approval is not an authorization boundary against an untrusted client." When an agent is served through a UI adapter, the client that sent the request is also the one returning approvals, so a malicious client can approve its own calls. Pydantic's guidance is that approval protects against unwanted model actions, while real authorization has to be enforced inside the tool function itself.

That matches what the advisories show. GHSA-jpr8-2v3g-wgf9, published July 2026, described a case where the UI adapters' message sanitizing could be sidestepped so that "A remote client could use this to have a registered server tool run with arguments it supplied rather than arguments the model produced." It was fixed in 1.107.1 and 2.5.0, and the advisory notes that teams relying on model-request hooks for guardrails were the most affected, because forged calls skip the model turn entirely.

Our human approval for AI agents page explains how the gateway hold works, including timeouts and what the approver sees.

Pydantic AI 2.0.0 went stable on June 23, 2026, after betas that started May 20. Pydantic's version policy says: "We'll continue to provide security fixes for V1 for at least 6 months after V2's stable release, so you have time to upgrade your applications." Six months from June 23 is roughly December 23, 2026. After that, a V1 agent has no promise of patches, and the V1 line did receive security backports in September (1.107.6 carried the four fixes from 2.44.0).

Most of the V2 changes are renames, but several touch the controls security teams care about. These are the ones to review, not just recompile.

The first row deserves a test of its own. Under V1's early strategy, a model that produced its final output and a tool call in the same response often never ran that tool. Under V2's graceful strategy it does. For a read tool that is harmless. For a tool that sends email or moves money, it is a behavior change you want to see in staging, not in production.

Pydantic publishes advisories promptly and fixes them fast, which is to its credit. Ten appeared on the project's GitHub security page between June and September 2026. None is a flaw in the core agent loop; they cluster in the parts of the framework that touch the outside world: fetching URLs, serving a chat UI and exporting telemetry.

The earlier SSRF issue, CVE-2026-25580, affected URL downloads before 1.56.0. The pattern across all of them is the same one we see on every framework: the moment an agent can fetch a URL or be reached from a browser, the attack surface is the network, not the model. Upgrading closes each known bug. It does not give you a policy on which domains an agent may fetch from in the first place, or a record of what it fetched and why.

Two notes on the telemetry advisories, because they are easy to dismiss. If you export spans to a third-party backend and set include_content=False to keep customer data out of it, those bugs meant some content went anyway. Treat traces as business data, restrict who can read them, and do not rely on one flag as your data-loss control. Our AI data leak prevention page covers where redaction belongs.

Pydantic AI Harness, a separate package from core, now ships input, output and tool guardrails as capabilities. In Pydantic's words, guardrails "put a validation layer on the three edges of an agent run". The built-in detectors redact secrets, redact personal data such as card numbers and US Social Security numbers, and block keywords. Pydantic is candid about the limit: "A regex finds a credential because credentials have a shape. It does not find a prompt injection, which is ordinary language." It also notes that during run_stream() an output guardrail runs on the final output only, so a block cannot un-send chunks already streamed.

Two of those six rows say buy nothing, and we mean it. A single internal agent that reads data, with no write tools and no web fetch, is well served by Pydantic AI plus Harness. Agents that answer from a vector store carry their own version of the injection problem, covered on our RAG security page. The case for a runtime layer starts when an agent can change something that matters, when it reads untrusted content from the web or email, or when you run more than one framework and want one set of rules.

You keep writing agents exactly as before. The change is where outbound calls go.

1. Inventory tools with side effects. List every function tool, MCP server and external API your agents can reach, and mark which ones write, send, pay or delete. Include web_fetch and anything that reads email or documents, because that is where injected instructions arrive.
2. Route MCP and HTTP through the gateway. Point your MCPToolset servers at the AgentShield MCP gateway and your HTTP tools at the AgentShield proxy. Pure in-process functions that only compute stay as they are.
3. Write policy per tool. Allow reads broadly, cap writes by value, deny anything a given agent should never touch. Our AI agent permissions management is where those rules live, and they apply no matter which framework made the call.
4. Keep requires_approval, and move the approver. Pydantic's deferred tools still pause the run cleanly. Pair them with a gateway hold so the final yes comes from a named person in your organization, not the client that made the request.
5. Record decisions, not just spans. Each verdict lands in a tamper-evident audit trail with requester, tool, validated arguments and outcome, alongside the OpenTelemetry traces you already export, and live agent monitoring flags unusual tool activity as it happens.

Teams running Pydantic AI next to other frameworks should compare notes with our LangChain security and OpenAI agent security pages, since the same policy covers both. For tool servers you build yourself, MCP server security covers what to lock down on the server side.