Spend policies and data protection run on the request path: when a limit is met, the call simply does not go out. Every allowed call lands in the same trace as the queries and tools around it, so the audit log is the agent's actual trajectory, queryable with SQL.
-- Spend by agent and model, last 7 days.
select
attributes->>'gen_ai.agent.name' as agent,
attributes->>'gen_ai.request.model' as model,
sum(cast(
attributes->>'operation.cost' as double
)) as usd
from records
where start_timestamp > now() - interval '7 days'
and attributes->>'gen_ai.operation.name'='chat'
group by agent, model
order by usd desc;One is a control point: something on the request path that can refuse. A budget is met, so the call does not go out. A prompt carries a card number, so it is redacted or blocked. A model is not on the allow list, so it is unreachable. The decision happens before the provider sees the request.
The other is a register: a system of record for which agents exist, who owns them, what risk they carry and what evidence you can produce when someone asks. It does not sit on the request path at all.
Both are sold as AI governance and only one of them can stop anything. This page is the first kind, plus the part most control points leave out: the record of what an allowed call went on to do. If your deliverable is an attestation binder, you want the second kind as well, and the two are usually bought separately.
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.
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.
There is no risk questionnaire, no policy pack and no attestation workflow, and there is no approval step that routes a high-risk action to a person before it runs. Those are real parts of this category and naming them is cheaper than letting you find out during an evaluation.
What is here is the enforcement point and the evidence: a policy that refuses, a guardrail that inspects, an allow list that holds, and a trace of everything that got through. Governance registries consume that evidence well, and pairing one with this is a reasonable end state.
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. The category contains two different products: a control point on the request path that can refuse, and a register that records which agents exist and what risk they carry. Most enterprises end up with one of each.
A gateway is where most enforcement happens, because it is the one point every request passes through. It is not the whole of governance. Registration, risk assessment and attestation live in a different kind of product, and a gateway does not produce an evidence binder for a regulator.
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.
No. Routing a high-risk action to a person before it executes is a real part of this category and Logfire does not do it today. What is here is enforcement that is automatic, meaning a policy either allows the call or refuses it, plus the trace that shows what an allowed call went on to do.
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.
Indirectly. Logfire produces the runtime evidence: what ran, what it cost, and what was blocked. That is evidence an assessment consumes; the assessment itself lives elsewhere. If your deliverable is a filled-in framework and an attestation workflow, a dedicated AI governance registry is the right tool, and it can consume this evidence.
Get started with 10 million free spans, logs, and metrics per month, and 0% markup on your own provider keys. No credit card required.