AdPilot Spend Approval And Safety
AdPilot is designed to fail closed around spend. It can research, draft, monitor, and report without customer approval, but it cannot perform spend-changing actions until the customer approves the specific action.
This page documents the live spend model and default safety behavior for AdPilot.
Default Approval Model
The default model is strict per-action approval.
AdPilot requests approval before:
- Launching a campaign, ad set, ad group, or ad.
- Increasing a daily or monthly budget cap.
- Changing a bid strategy or target that can increase spend.
- Reactivating a paused campaign, ad set, or ad group.
- Expanding targeting or placements in a way that materially changes spend risk.
AdPilot does not request approval for read-only reporting or spend-reducing safety actions such as auto-pause. Reactivation after an auto-pause is spend-changing and does require approval.
The configured monthly budget cap is enforced server-side before spend writes using the AdPilot spend ledger. If the monthly cap is exhausted, AdPilot blocks launches, budget increases, bid changes that can increase spend, and reactivation even if an approval card exists.
What Each Approval Shows
Each approval card should show enough detail for the customer to decide without opening the provider console.
| Field | Purpose |
|---|---|
| Provider | Google Ads, Meta Ads, or LinkedIn Ads. |
| Ad account | The exact account where the action will run. |
| Action type | Launch, budget increase, bid change, reactivation, or scope expansion. |
| Campaign or entity | Campaign, ad set, ad group, ad, or provider entity ID when available. |
| Spend amount | Daily budget, monthly cap, incremental increase, and currency. |
| Objective | Campaign objective and optimization goal. |
| Conversion event | Event name AdPilot will monitor, such as signup or purchase. |
| Landing URL | Destination URL for the approved action. |
| Audience summary | The audience or targeting change being approved. |
| Creative summary | Ad copy, headline, description, or creative variant summary. |
| Reason | Why AdPilot recommends the action. |
| Guardrails | Target CPA/ROAS, pacing limits, and auto-pause conditions. |
| Expiration | When the approval becomes stale and cannot be used. |
For CAPI-backed campaigns, the approval should also show whether conversion tracking verification passed. See CAPI setup.
Approval Outcomes
| Outcome | Behavior |
|---|---|
| Approve | AdPilot can run only the specific action shown on the card. |
| Reject | The action is blocked and cannot resume from that approval. |
| Expire | The action becomes stale and requires a new approval. |
| Edit requested | AdPilot drafts a revised plan and sends a new approval. |
| Provider/auth changed | The approval becomes stale if the provider account, token, account selection, or spend payload changed. |
Approval is bound to the provider, ad account, action, amount, currency, and idempotency key. If those values change, AdPilot must request a new approval.
Reject Behavior
Rejecting a plan is the safest way to stop a proposed spend-changing action.
When you reject:
- No campaign launch, budget increase, bid change, or reactivation runs from that approval.
- The rejected approval cannot be resumed later.
- The rejection reason is preserved for audit and can guide the next draft.
- Existing campaigns are not changed unless a separate approved action or auto-pause applies.
- AdPilot can generate a revised plan, but the revision requires a new approval.
Use rejection reasons such as budget too high, wrong audience, creative not approved, tracking not verified, compliance concern, or hold for later.
Trust Window
No trust window is enabled by default.
A trust window would let AdPilot make bounded spend-affecting changes after one broader approval, such as small bid changes within a fixed percentage for a fixed period. That is a separate product decision and should not be assumed for launch copy.
Until a trust-window policy is explicitly enabled, customers should expect per-action approval for every spend-changing recommendation.
If a trust window is introduced later, the approval card should show:
- Start and end time.
- Maximum total spend.
- Maximum per-change increase.
- Included providers and ad accounts.
- Included campaign or entity IDs.
- Actions allowed without another prompt.
- Actions still requiring separate approval.
Auto-Pause And Reactivation
Auto-pause is allowed because it reduces spend risk. AdPilot can pause underperforming or unsafe entities when a configured guardrail trips.
Reactivation requires approval because it resumes spend. The reactivation approval should show:
- Why the entity was paused.
- What changed since the pause.
- The account and entity to reactivate.
- The spend cap after reactivation.
- The monitoring guardrails that will apply.
See AdPilot troubleshooting for recovery steps after an auto-pause.
Stale, Replay, And Tamper Protection
An approval should be treated as stale when:
- The approval expired.
- The selected provider account changed.
- The OAuth token changed in a way that changes account visibility.
- The budget, currency, campaign objective, conversion event, or target entity changed.
- The action already ran.
- The customer rejected the approval.
AdPilot should not replay an old approval for a different action. It should request a new approval whenever the spend payload changes.
Customer Checklist
Before approving, confirm:
- The provider and ad account are correct.
- The spend amount and currency match your budget.
- The conversion event is verified.
- The landing URL and audience match the intended campaign.
- The creative and compliance notes are acceptable.
- The auto-pause guardrails are clear.
- You understand when the approval expires.
Return to AdPilot.