Running paid media from an AI agent without losing control

Most discussion of agent risk in advertising is about output quality: will it write a bad headline, will it pick the wrong segment. Those are real and they are recoverable. The unrecoverable failures are operational, and they come from the fact that advertising APIs were designed for a human operator who can look at a confusing response, frown, and go and check before pressing anything else.

Given a response it cannot parse, an agent's default behaviour is to try again, and a retried activation against a vendor that did in fact accept the first one produces two live campaigns spending in parallel. That is not a hypothetical: it is the ordinary failure mode of any distributed system without idempotency, and it costs money at the exact rate the campaign was budgeted to.

So the design questions worth asking before you connect anything are boringly infrastructural. What can it reach? Whose authority does the call carry? What happens when a supplier answers ambiguously? Who can undo it?

The first thing to establish about any agent integration is whether the agent's route into the system is the same one the user interface uses. Two paths mean two sets of rules, and the second set is always weaker, because it was written later and by someone thinking about tool ergonomics rather than about money.

In AdBuyMCP each of the 105 MCP tools is a thin wrapper over exactly one REST endpoint, the same endpoint the browser calls, so both routes share the same tenant boundary, spending check, approval record and audit trail. An agent can do nothing through MCP that a person could not do in the product, and nothing that a person did not authorise, because there is no second execution path to hold different rules.

Because the tool surface is a subset of the API rather than a mirror of it, operations can be omitted from it entirely. Eleven consequential operations have no MCP tool at all, among them resolving an approval, replacing or revoking a mandate, closing a mission, verifying a supplier dossier, and issuing or revoking a live execution grant. The API keeps more for people than this list. Supplier booking confirmations, managed stops, spend-lock resolution, provider-spend reconciliation, brand-lift purchases and identity-cohort imports are human-only as well, and no tool reaches any of them. An operation with no tool is a stronger guarantee than a permission the agent is asked not to exercise, because there is nothing to exercise.

An API key cannot limit what an agent does. The agent gets everything the key allows or nothing, and the only way to stop it is to revoke the key, which takes the integration down with it.

The alternative is to make authority a durable object. Here the chain is mission, mandate, run, ordered steps, decision and evidence. A mission is a named objective owned by your workspace, and agents cannot close their own. A mandate is a revocable, versioned grant enumerating exactly which actions are allowed, in which currency, for how long, and up to what money ceiling. Work proceeds as ordered steps against that mandate, each recorded, and a step cannot be skipped or a run silently restarted.

Two properties of that model are worth copying whatever platform you are on. Authority is time-bounded, so an agent that is forgotten about stops being able to act rather than continuing indefinitely. And it is versioned and revocable as data, so withdrawing authority is an ordinary operation with an audit trail rather than an emergency credential rotation.

The weakest common form of human-in-the-loop is a confirmation dialogue: the agent asks, a person says yes, and the agent then does something. What it actually does is not necessarily what was described, and the gap between the two is where the loss lives.

The stronger form binds the approval to a digest of the exact action. A human approves a specific set of bytes; the approval is single-use; and when a request arrives, it is checked against that digest. If it does not match, it fails closed rather than proceeding on the strength of something that looks similar. That converts "the agent did something I did not expect" from a plausible incident into a structural impossibility.

Approving evidence should not enable spend: on this platform, enabling spend on a staged live line is a separately granted action that an approval alone cannot perform, so a single yes cannot cascade into money moving. And an agent credential must not be able to resolve a human approval at all: on AdBuyMCP an agent that tries to approve its own work receives a 403 response that requires a human.

The most consequential design decision in the AdBuyMCP server is a refusal: a human's ordinary web session cannot be forwarded as an agent's credential. The attempt fails with a 401 rather than quietly working.

If a logged-in person's session can be handed to an agent, the agent inherits everything that person can do, which in most systems includes approving work. Every guarantee above evaporates at that point, and it evaporates silently, because from the server's point of view a person is acting.

The implementation is that every request carries a verified actor class that cannot be changed by adding or removing headers. Human sessions are classified as human and web; the MCP client's fixed source marker makes the human-plus-agent pairing fail rather than take the browser path. An agent credential must be either a configured service token or a verified delegated token carrying a signed agent claim and a non-empty verified client identifier. Actor, source and client attribution are then persisted on every action, so the audit log answers "who did this" rather than "which account did this".

Poor failure handling costs more than a poor happy path, because it can leave two live campaigns spending where you meant to launch one.

The rule that prevents the expensive version is that an ambiguous outcome stops the run. Where a supplier's response cannot be read confidently, the run raises an exception, halts, and waits for an explicit human resolution before resuming. It is never blindly retried. That single rule prevents the specific incident this whole design exists around: an agent that cannot tell whether an activation succeeded, trying again.

Underneath it sits the mechanism that makes retry safe when retry is right. Every outbound side effect writes a committed provider-attempt record before the call and settles it afterwards, keyed by a deterministic idempotency token that is passed to the vendor and reused on retry. After a crash, orphaned attempts are reconciled first: sandbox orphans close automatically, and live media or creative orphans move the line to reconciliation-required rather than being retried or assumed failed. You are given the vendor, the operation and the token, so the question "did this actually happen?" is answerable by checking rather than by guessing.

An expired or blocked supplier authority also raises a spend lock before any scheduler work runs, sends a single incident-bound emergency pause, and refuses to retry an ambiguous response. Only a signed human reconciliation clears it, and re-verifying then revoking again uses a fresh incident identifier rather than reopening the resolved one.

AdBuyMCP runs the hosted MCP server. Approved accounts sign in through Supabase, select their workspace and consent. Each compatible external client needs its own approved OAuth identity and exact callback registration. There is no public connector or registry listing. The server speaks streamable HTTP, works behind load balancers without sticky routing, and is fail-closed at the boundary: every deployment AdBuyMCP runs has to name its exact allowed hosts and browser origins, and a modern HTTP request that omits its protocol version header is rejected before dispatch.

Supabase is the hosted authorisation server. The MCP server publishes protected-resource metadata, validates short-lived grants with PKCE S256 and resource audiences, and delegates to the API under a separate audience. Server-owned claims define workspace and product access. Automatic client registration is disabled: the client's own identity and exact callbacks must be approved, and compatibility with pre-registration needs checking for each client. A human dashboard session cannot be substituted for an MCP grant.

The tool annotations are easy to over-trust. The server marks tools read-only, destructive, idempotent and open-world, and those labels look like a security control. The server's own documentation says they are not one, and the MCP specification tells clients to treat annotations as untrusted unless they come from a trusted server. They are discovery hints that help a client decide what to surface and what to confirm. The boundary is the API's fail-closed execution hook, which rejects any consequential call that does not match a registered action and an approval granted for those exact bytes.

Whatever you end up using, these are the questions worth asking before a budget is attached, and they are all answerable in a sentence by anyone who has thought about it.