How Synter's Fail-Closed Safety Gates Protect Ad Spend

An AI agent operating a live ad account has real consequences. A wrong targeting configuration sends budget to the wrong country. A misplaced bid modifier depletes spend in hours instead of days. A creative that violates platform policy gets an account flagged. The agent does not feel any of these outcomes. The advertiser does.

The failure mode is not the agent trying to do something malicious. It is the agent trying to be helpful, calling a tool it is not supposed to call, or calling a legitimate tool with parameters that are technically valid but operationally wrong. The agent does not know the difference between a geo target that costs $500 and one that costs $50,000. The ad platform API does not care. It will accept both.

This is why Synter built its safety architecture around a core principle: fail closed. When something is ambiguous, uncertain, or outside the explicit allowlist, the default state is blocked, not permitted.

The first and most fundamental safety layer is the tool registry. Every Synter script that can touch an ad account is registered in a central allowlist. The registration includes the script name, parameters, expected credit cost, timeout configuration, and a classification of the operation type (read, write, destructive).

When an AI agent calls a tool, the request goes to the dispatcher. The dispatcher looks up the script name in the registry. If the script is found, execution proceeds. If it is not found, the dispatcher throws UNKNOWN_TOOL immediately. No fallback. No retry. No partial execution. The call is blocked.

This means a creative AI agent cannot discover novel ways to call ad platform APIs. It cannot combine partial tool names to construct an unregistered operation. It cannot call a tool that was valid last week but was removed from the registry. The allowlist is the complete set of permitted operations, and it is checked on every single call.

Error: UNKNOWN_TOOL
Tool "tiktok_create_campaign_v2_experimental" is not registered
in the Synter allowlist. Execution blocked.

Registered tools for this platform: 42
Call stack: agent → dispatcher → registry lookup → BLOCKED

The UNKNOWN_TOOL error is specific and actionable. It tells the agent exactly which tool was attempted and that it is not registered. The agent surfaces this to the user. The user knows what happened. No silent failures, no partial operations, no ambiguous state.

How This Compares to Generic MCPs

A generic ad platform MCP wrapper passes tool calls through to the raw API. If the API accepts the call, the call goes through. There is no allowlist check. There is no registry. The set of permitted operations is the set of operations the API supports. That is an unbounded surface, and it grows every time the platform adds API endpoints.

The difference matters in production. You want AI agents operating in a bounded, explicit, auditable set of operations, not an unbounded raw API surface where the only gate is whether the platform accepts the call.

Geo policy enforcement runs before any location mutation. Before any targeting change that adds, modifies, or extends geographic coverage, the geo policy gate checks the proposed target list against a set of restricted regions.

This gate exists because of a real incident. An agent, attempting to expand campaign reach as instructed, added a broad geographic target that included countries the customer had explicitly not authorized. The platform accepted the mutation. The campaign ran. The customer noticed the next day when the spend report showed geographic distribution they had not approved.

We fixed it permanently. Now geo policy enforcement works as follows:

• Synter maintains a list of restricted regions that require explicit customer opt-in. This list is configurable per account.
• When an agent attempts a location mutation, the proposed target list is checked against the restricted set before any API call is made.
• If restricted regions appear in the target list without a recorded opt-in, the write is blocked. The error specifies which regions triggered the block.
• The customer can provide explicit opt-in for specific regions, which is recorded and checked on subsequent calls. The opt-in does not expire silently.

Spend cap enforcement is a two-layer system. The first layer is credit balance checking. The second layer is campaign-level spend limits.

Layer 1: Credit Balance Checking

Every Synter script carries an explicit credit cost. Read operations cost 2 credits. Write operations cost 5 credits. A full campaign launch including creative upload, audience build, and ad group configuration costs significantly more. The costs reflect actual API load, compute per operation, and the relative risk of each action class.

Before every execution, Synter checks the current credit balance against the operation cost. If the balance is insufficient, the call fails before making any API calls to the ad platform. The customer sees a specific error: insufficient credits for this operation, with the cost and current balance both reported. No partial operations, no calls that start and cannot complete.

Layer 2: Campaign Spend Limits

Beyond credit balance, customers can set explicit per-campaign and per-platform spend limits. When an agent attempts to modify a campaign budget, create a new campaign, or otherwise affect spend, the agent checks these limits before execution.

A budget increase request that would exceed the customer's configured limit is blocked. The agent reports the limit and the proposed amount. The customer can approve the exception explicitly, which is recorded before the operation retries. No silent budget overrides.

Not every operation can be fully autonomous. Synter identifies a class of high-impact operations where the cost of an error is high enough that explicit customer approval is required before execution. The approval is recorded and checked at execution time.

Operations that require customer approval include:

• Campaign deletions. Deletion is irreversible. An agent can pause a campaign autonomously, but deleting it requires explicit approval.
• Budget increases above a configured threshold. The default threshold is 50% of current budget. Any proposed increase above that percentage requires approval before the write goes through.
• Adding new ad platforms to an account. Connecting a new platform or expanding to a platform not previously active for the customer.
• Audience operations involving uploaded first-party data. Creating customer match audiences, uploading email lists, or creating lookalikes from first-party data.

The approval flow works within the conversational interface. The agent presents the proposed operation, explains what it will do, and requests explicit confirmation. The customer types approval. The agent records it and proceeds. No out-of-band emails, no separate confirmation UI. The approval lives in the conversation thread.

Every write operation touching an ad account runs through all four gates in sequence. Each gate is independent. Passing one does not waive the others.

The result is an AI agent that can operate autonomously on routine operations (bid adjustments, status changes, performance queries, creative variations) while being gated on operations where the cost of an error is high (geo expansion, budget increases, deletions, first-party data operations).

This is not a configuration option. It is not a feature flag. These gates are baked into every execution path. An agent running on Synter cannot route around the safety layer any more than it can route around the credit billing layer. They are the same system.