Put spend ceilings, sensitive-data checks, and model allow lists on the path every model request takes. Pydantic AI Gateway can refuse requests that violate a blocking policy, while Logfire records the decision beside the trace of what the agent did next.
action: block · matches: 1 Trusted by teams building production software and AI
Agents do not execute policy documents. A control has to run on the request path: when a blocking budget is met, the call does not go out; a prompt carries a card number, so the configured action can observe, redact, or block it; a model is not on the allow list, so it is unreachable. The decision happens before the provider sees the request, and the result is recorded in the same OpenTelemetry trace.
That makes governance part of the system rather than a report assembled after an incident. The policy decision, the identity behind the request, the model call, and the downstream work remain connected, so a team can explain not only what was blocked but what every allowed agent run went on to change.
Every step an agent takes is an OpenTelemetry span: the model call, the tools it invoked, the queries it ran, in order, with the key and organization member behind them. There is no parallel audit record to reconcile against what actually happened; the run itself is the record, and it outlives the conversation.
A spend policy is checked as each request arrives, and once a limit is met the call is refused: a daily ceiling to catch the runaway loop, a monthly one to hold the budget. Guardrails inspect the prompt before it leaves your boundary, with regex for structured secrets and third-party DLP solutions like Presidio, hosted by you, for personal data with no fixed shape.
The same telemetry that governs also improves. At the gateway, routing weights and price overrides let you move traffic toward the provider winning on cost and latency, under spend ceilings that make the experiment safe. At the prompt, the optimizer reads production runs and proposes changes with the evidence attached.
An agent's action does not end at the model response. The trace follows it into the services it called, the rows it wrote and the jobs it kicked off, so 'what did this agent change' is answered from the same store as 'what did it cost', across everything you instrument. Attach your own attribute for the person an agent acts for and it groups by that too.
Enforcement lives in Pydantic AI Gateway, which has the detail on how each policy is configured and how it compares to the other enforcement points, and the prompt half of the optimization loop is the agent optimizer. The trajectory and the enterprise trace are what the rest of this page is about.
Bring the controls, audit evidence, and deployment constraints your team needs. We’ll tell you plainly where Logfire fits.
Gateways enforce and observability platforms explain, and the usual arrangement is one of each with a correlation ID between them. That works until the question spans the boundary. A finance owner asks why last month cost what it did; the gateway can say which key spent it and the traces can say what the agent was doing, and joining those two answers is a project.
Here the enforcement decision and the work that followed it are records in the same store. Blocks, spend and the agent's database queries,
retries and tool calls are all queryable with PostgreSQL-compatible SQL, so attribution is a group by. The same interface is
available to coding agents through Logfire's MCP server.
Controlling what an agent may do at runtime: which models it can call, how much it can spend, and what data may leave with its prompts. It also means being able to show afterwards which agent did what, which policy applied, and what happened after the decision.
Pydantic AI Gateway applies controls on the request path before a model provider receives the call. Logfire records the policy result alongside the agent trace, so the enforcement decision and the work it affected can be investigated together.
Cost tracking reports what you spent. A spend policy refuses the request once a limit is met. Both are useful and only one of them helps while the incident is still happening, which is why the limits here are checked on the request path as each call arrives.
Two loops over the same telemetry. At the gateway level, routing groups carry a priority and a weight, so you can shift traffic toward the provider that is winning on cost and latency and override catalog prices to match your negotiated rates, with spend ceilings holding the floor under any experiment. At the prompt level, the optimizer reads production runs and proposes prompt changes with the runs cited as evidence. Governance provides the data both loops need.
Yes, and that is the point of the design. Regex protections run in the gateway, and detection for unstructured personal data calls out to a service you run, so classification happens inside your boundary. You also choose what happens if that detector is unreachable: fail open and let the request through, or fail closed and block it.
Logfire preserves runtime evidence: what ran, which policy applied, what it cost, and what was blocked. Teams can query and export that evidence for internal reviews, incident investigations, and the compliance processes they operate.
Get started with 10 million free spans, logs, and metrics per month, and 0% markup on your own provider keys. No credit card required.