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.

An agent has no frown. Given a response it cannot parse, its 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? Everything else is a preference.

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 76 MCP tools is a thin wrapper over exactly one REST endpoint — the same endpoint the browser calls. One tenant boundary, one wallet gate, one approval record, one 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.

The corollary is the interesting half. 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: resolving an approval, resolving a campaign provider attempt, acknowledging a booking-workflow step, resolving an asset job, replacing a mandate, revoking a mandate, closing a mission, saving a supplier dossier, verifying a supplier dossier, issuing a live execution grant, and revoking one. 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.

"Give the agent an API key" is not an authority model. A key is a binary: either the agent has everything the key can do, or it has nothing, and revoking it is an outage rather than a control.

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.

Two refinements matter as much as the mechanism. 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 — an integration test proves an agent attempting to approve its own work receives a 403 requiring human approval.

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.

That sounds like a technicality and it is the whole ballgame. If a logged-in person's session can be handed to an agent, the agent inherits everything that person can do — including, in most systems, 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".

Design the happy path badly and you get a wrong campaign. Design the failure path badly and you get two.

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.

One more control belongs in the same family. An expired or blocked supplier authority 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.

MCP access to AdBuyMCP today is a private, single-tenant, self-hosted deployment behind a bearer token or your own tunnel. There is no public connector to add and no multi-tenant sign-in. The server runs over both streamable HTTP and stdio, works behind tunnels and load balancers without sticky routing, and is fail-closed at the boundary: production must set exact allowed hosts and browser origins, local execution binds to loopback unless a container deployment opts out explicitly, and a modern HTTP request that omits its protocol version header is rejected before dispatch.

Public multi-tenant MCP needs an OAuth 2.1 authorisation server issuing per-user, per-organisation, audience-bound tokens. The package deliberately does not embed one — it publishes protected-resource metadata and scope challenges, and startup fails if OAuth is mixed with static tokens — and choosing the issuer, the client registration, the callback allowlist, the consent model and the tenant claim is an open launch gate rather than a configuration step. A static bearer token is suitable only for a deployment serving one organisation.

One thing to hold lightly: the tool annotations. The server marks tools read-only, destructive, idempotent and open-world, and those labels look like a security control. They are not, and the server's own documentation says so. 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.