Secure Marketing Agents: A Reference Architecture for DV360 and Google Ads Automation

A campaign optimisation agent becomes interesting the first time it can do more than explain a dashboard.

It reads DV360 performance. It sees a line item losing efficiency. It checks Google Ads search terms, notices budget pressure moving from one market to another, and drafts a change: reduce bids here, shift budget there, narrow one audience, expand another.

That is the useful version of marketing agents. The difficult part starts one step later.

Who gave the agent permission to make that change? Which advertiser was the permission valid for? Was the approval tied to one action or to the whole account? Can the system prove what the agent saw, what it proposed, who approved it, and what API payload finally reached Google?

Most early agent builds answer those questions with a convenient shortcut: a human connects a Google account, the app stores the OAuth token, and the agent operates through that user’s access. It works in a prototype. It becomes fragile in production.

A senior trader may have access to dozens of advertisers. A regional lead may have inherited seats across brands and markets. A service account may have broader platform permissions than the agent needs. Once the model can trigger writes, broad authentication turns into broad blast radius.

The safer architecture is already visible in another market: agentic commerce. Google, Shopify, and Stripe are building systems where agents can discover products, prepare checkouts, and help complete purchases without receiving raw payment authority. Their implementations differ, but the pattern is consistent: separate discovery from execution, grant scoped authority, record approval, and keep the final transaction behind a controlled service.

That pattern transfers directly to marketing automation.

This guide turns the commerce pattern into a reference architecture for DV360 and Google Ads agents: identity, policy, intelligence, execution, audit, and organisational governance.

Contents

• The Commerce Pattern Marketing Should Copy
• Why Personal OAuth Breaks for Agents
• The Five-Layer Architecture
• Trust Zones
• Centralised Agent Authentication
• Threat Model
• The Build Cycle
• Caveats
• What To Build Next
• Companion Skills Pack
• Reference Reading

This article continues our work on secure agent harnesses, marketing skills, and agent infrastructure. It connects especially closely to our security harness guide and our Google Cloud Next 2026 analysis, where agent identity and control-plane design became the core theme.

The Commerce Pattern Marketing Should Copy

Agentic shopping reached the delegated-authority problem before campaign automation did. A shopping agent can browse products freely, but payment needs a tighter contract. The system needs to know what the buyer approved, which seller can charge, how much can be charged, when the permission expires, and what happens if the agent tries to exceed that boundary.

Google, Shopify, and Stripe each solve part of that problem.

The common pattern is simple: the agent can initiate or prepare an action, while a separate control layer authorises and executes it.

For ads automation, replace “payment” with “campaign write”. A bid change, budget shift, targeting edit, or product-feed update deserves the same treatment as a delegated payment: scoped, approved, bounded, logged, and reversible.

Google: Mandates and Protocol Boundaries

Google’s Universal Commerce Protocol standardises the exchange between an AI agent and a merchant backend, with support for API, MCP, and A2A-style bindings. In parallel, Google’s Agent Payments Protocol uses mandates to express user approval for agent-initiated payments.

The marketing translation: do not treat platform access as a general-purpose credential. Treat each meaningful campaign change as a mandate-like object:

• advertiser: which account or partner seat is in scope
• entity: campaign, insertion order, line item, ad group, keyword, audience, or feed item
• action: bid change, budget change, targeting update, creative status change
• limit: maximum allowed change
• expiry: how long the approval remains valid
• approver: who authorised it
• audit anchor: what evidence proves the approval existed

That moves the system from broad account access to bounded action authority.

Shopify: Trust Tiers and Merchant Control

Shopify’s agent documentation focuses on staged commerce flows: discovery, cart, and checkout. It also gives merchants control over agent access, rate limits, and required interactions.

The marketing translation: an agent should not start with write access because it produced one good recommendation. Trust should grow in stages:

This lets teams adopt agents without giving every prototype full ad-account authority.

Stripe: Scoped Tokens for Execution

Stripe is the clearest payment example. Its Agentic Commerce Suite uses hosted commerce endpoints and Checkout Sessions, while Shared Payment Tokens give agents delegated payment authority with hard limits such as seller, amount, currency, and expiry.

The marketing translation: create short-lived internal execution grants for write operations.

A campaign-change token could carry:

{
  "workspace_id": "client-123",
  "platform": "dv360",
  "advertiser_id": "987654",
  "entity_type": "line_item",
  "entity_id": "li_456",
  "allowed_action": "apply_bid_delta",
  "max_delta_percent": 10,
  "expires_at": "2026-05-06T18:00:00Z",
  "approval_id": "approval_abc"
}

The agent never receives the underlying Google refresh token. It receives permission to request one bounded operation through a controlled executor.

Why Personal OAuth Breaks for Agents

The familiar OAuth pattern is convenient for dashboards and internal tools:

1. A user signs in with a Google account.
2. The app requests DV360 or Google Ads scopes.
3. The user consents.
4. The app stores a refresh token.
5. API calls run under that user’s access.

For agentic workflows, the same pattern creates several failure modes.

Broad Access Travels With the Token

The Google Ads scope and the DV360 scope are powerful. In an agency environment, one user may have access to many advertisers. If the agent uses that user’s token, the agent inherits that access unless the application adds its own scoping layer.

A campaign agent usually needs one workspace, one advertiser, and one task. The token may expose much more.

Human Identity Becomes System Identity

If the agent writes through a human’s token, the downstream platform records the human identity. That makes the audit trail misleading. The trader did not personally decide the change; the agent did, under a system workflow.

It also creates operational fragility. If the employee leaves, changes roles, or loses access, the automation built on their token can break.

Read and Write Share the Same Credential

Most early builds use one token for everything: read performance, inspect targeting, create recommendations, and apply changes. Observation and execution share a permission boundary.

A safer design separates those modes. Reading can be broad enough to produce useful analysis. Writing should be narrow, policy-checked, and tied to a specific approval.

Approval Is Missing From the API Call

The API call only proves that a credential had permission. It does not prove that a human approved this specific budget increase or targeting expansion.

The approval record needs to exist as a first-class object in the platform, linked to the proposed diff and the executed payload.

Multi-Client Isolation Becomes an Application Burden

Google will enforce platform permissions, but it will not know your internal workspace model, client separation, team ownership, or market boundaries. The agent platform has to enforce that layer itself.

The Five-Layer Architecture

A secure marketing-agent platform needs five layers:

1. identity and consent
2. policy
3. read-only intelligence
4. execution
5. audit and rollback

Each layer has a clear responsibility. The model reasons. The policy layer governs. The executor writes. The audit layer remembers.

Layer 1: Identity and Consent

Users still connect Google Ads and DV360 accounts through OAuth where required. The difference is what happens after consent.

The platform should route access through an authorisation broker:

• store refresh tokens in a vault
• map tokens to workspace, advertiser, platform, environment, and owner
• prefer service-account or service-identity patterns where the platform supports them
• issue short-lived internal grants for specific operations
• keep long-lived credentials away from prompts, tool outputs, logs, and agent memory

Google’s OAuth guidance stresses least-privilege scope selection. Google Ads service-account documentation also shows how backend access can avoid tying every operation to an individual employee’s personal login.

Practical rule: the user’s account grants access to the platform. The agent receives task-level access from the platform.

Layer 2: Policy Engine

Every proposed write should pass through a deterministic policy engine before it reaches an API executor.

The policy engine checks:

• action type
• advertiser and workspace
• entity type and entity ID
• requested budget or bid delta
• targeting breadth
• geography and regulated category sensitivity
• recent changes to the same entity
• whether approval is required
• whether the agent is trusted for this operation

Policy should be code or configuration, not prose hidden inside a system prompt.

Example policy rules:

The LLM can explain why a change is useful. It cannot grant itself authority to make the change.

Layer 3: Read-Only Intelligence

The intelligence layer is where the agent does useful marketing work:

• read campaign structure
• inspect performance trends
• compare pacing against goals
• identify targeting constraints
• detect anomalies
• draft change plans
• explain expected impact

The tools in this layer should be read-only and intent-specific:

read_campaign_state
analyse_line_item_performance
compare_targeting_options
estimate_budget_impact
inspect_change_history

The output should be a structured diff rather than a free-form recommendation:

{
  "action": "propose_bid_delta",
  "platform": "dv360",
  "advertiser_id": "987654",
  "line_item_id": "li_456",
  "current_bid": 1.20,
  "proposed_bid": 1.08,
  "delta_percent": -10,
  "rationale": "CPA increased 22% while conversion volume stayed flat for 5 days.",
  "risk": "medium",
  "requires_approval": true
}

This keeps the agent valuable while keeping write authority outside the model runtime.

Layer 4: Execution Service

The executor is a narrow service that applies approved changes through Google Ads or DV360 APIs.

It should:

• accept only structured, policy-approved actions
• retrieve credentials from the broker at execution time
• validate current platform state before writing
• apply changes through the correct API method
• queue writes to the same entity
• verify post-write state
• store a rollback patch

DV360 makes this especially important. Google’s targeting guidance notes that targeting changes can fail because of configuration constraints, deprecated options, or concurrency issues. The executor should retrieve current targeting, compute the diff, apply bulk edits where appropriate, and avoid simultaneous updates to the same line item.

The executor is the marketing equivalent of Stripe Checkout or a payment processor. It owns the final write, not the agent.

Layer 5: Audit and Rollback

Every action should produce an audit record that can be replayed.

Minimum fields:

This layer turns agent execution into a governed operational process. It also gives marketing teams confidence: if an automated change performs badly, they can see why it happened and reverse it quickly.

Trust Zones

The five layers sit inside four trust zones.

The most important boundary is between the agent runtime and the execution zone. The model can request a change. The executor decides whether the request has a valid approval and a valid scoped grant.

This is the same design instinct behind agentic commerce: the agent may help a user buy, but the payment processor still controls the payment primitive.

Centralised Agent Authentication

A single team can build this architecture inside one product. A large marketing organisation needs a shared control plane.

Global agencies, holding companies, and enterprise marketing teams often have dozens of groups building agents against the same platforms. Without a shared authentication layer, each team stores tokens, defines policy, and writes audit logs differently. That creates inconsistent security posture and duplicated engineering work.

The central platform should own the security primitives while teams keep control of domain logic.

Centralise These Components

Authorisation broker. One service owns OAuth connections, service identities, token storage, refresh, rotation, and revocation.

Credential vault. All Google Ads, DV360, Meta, CRM, warehouse, and commerce credentials live in one governed secret store.

Base policy. The organisation defines minimum rules for spend, targeting, data export, publishing, and approval.

Execution gateway. Write-capable actions flow through a shared executor or gateway that enforces policy and logs results.

Audit pipeline. Security, compliance, and operations teams get one view of agent-initiated actions across clients, markets, and platforms.

Decentralise These Components

Agent logic. Teams own prompts, models, skills, optimisation strategies, and workflows.

Read-only analysis tools. Teams can build their own analysis and planning tools as long as write operations route through the governed executor.

Domain policy extensions. Teams can add stricter rules for regulated categories, high-budget accounts, local markets, or sensitive clients.

User experience. A search team, commerce team, and programmatic team may expose the same underlying control plane through different interfaces.

The operating model is important. The central platform should feel like a fast path, not an approval maze. Registration should be self-service for low-risk use cases. Policy failures should explain what needs to change. Secure authentication should be easier than pasting a personal token into a local script.

Threat Model

A useful architecture names the ways it can fail.

Credential Overreach

A user connects an account with access to many advertisers. The agent uses that token beyond the intended workspace.

Mitigation:

• least-privilege scopes
• workspace and advertiser mapping in the broker
• separate credentials per customer and environment
• no raw token access from the model runtime

Prompt Injection

A malicious campaign name, landing page, data feed, or external instruction pushes the model toward an unsafe change.

Mitigation:

• read/write separation
• deterministic policy checks
• approval gates for high-risk actions
• no direct write tools inside the LLM runtime

Concurrency and State Drift

Two processes update the same DV360 line item. The second update applies against stale state or fails because the platform rejects simultaneous targeting changes.

Mitigation:

• queue writes to the same entity
• retrieve current state before execution
• use bulk edit operations where supported
• verify post-write state
• store rollback patches

Unbounded Spend or Targeting Expansion

The agent proposes a change that increases spend, broadens reach, or expands into sensitive inventory faster than expected.

Mitigation:

• bid and budget delta caps
• daily change ceilings
• sensitive category deny rules
• step-up approval for broadening actions
• automated pacing checks after execution

Secret Leakage

Refresh tokens, service-account credentials, or API keys appear in prompts, logs, tool outputs, or agent memory.

Mitigation:

• vault-backed credential access
• executor-only secret retrieval
• redaction in logs
• no secrets in prompt context
• short-lived internal grants

Shadow Integrations

A team bypasses the shared platform and builds a personal-token integration because it feels faster.

Mitigation:

• make the secure path self-service
• provide good SDKs and templates
• monitor for unregistered API usage
• set clear organisational policy on agent credentials

The Build Cycle

Every write-capable marketing agent should follow the same cycle.

1. Read. The agent reads campaign state through scoped, read-only access.
2. Plan. The agent produces a structured diff with rationale, expected impact, and risk.
3. Validate. The policy engine checks scope, thresholds, workspace, platform constraints, and approval requirements.
4. Approve. Low-risk changes inside pre-approved boundaries can proceed; higher-risk changes go to a human.
5. Execute. The executor retrieves credentials, applies the change, and verifies the result.
6. Record. The audit layer stores the full transaction and rollback patch.

This gives marketing teams agentic speed without handing the model uncontrolled ad-account authority.

Caveats

Commerce protocols are design references, not drop-in ad-tech standards. UCP, AP2, Shopify agent tools, and Stripe SPTs solve commerce and payment problems. We are borrowing the security pattern: scoped delegation, explicit approval, and controlled execution.

Service-account support varies by platform and operation. Google Ads has documented service-account flows. DV360 support and operational suitability can vary by API surface and organisation setup. The broker should abstract those details rather than forcing every team to solve them.

Approval gates add latency. Low-risk operations may need pre-approved thresholds. High-risk changes deserve human review. The practical work is calibrating those boundaries per client, market, and channel.

Policy needs ownership. A policy engine without a policy owner becomes shelfware. Channel leads, platform engineers, security teams, and legal/compliance stakeholders need a clear process for changing thresholds and deny rules.

The hardest part is organisational adoption. The secure path has to be easier than the workaround. If teams can register an agent and get scoped access quickly, they will use the platform. If onboarding takes weeks, they will route around it.

What To Build Next

For marketing practitioners:

• List every agent or automation that touches Google Ads, DV360, Meta, CRM, commerce, or analytics systems.
• Identify which ones use personal OAuth or broad API tokens.
• Separate read-only workflows from write-capable workflows.
• Define which actions require approval: budget, bid, targeting, audience, product feed, publishing, tracking.
• Ask for an audit trail that shows proposed state, approved state, executed state, and rollback path.

For ad-tech engineers:

• Start with the authorisation broker and credential vault.
• Keep long-lived tokens out of prompts, memory, logs, and tool outputs.
• Express agent outputs as structured diffs.
• Put all writes behind a narrow executor.
• Add queueing for same-entity DV360 writes.
• Store pre-image, post-image, policy result, approver, and rollback patch.

For platform and security teams:

• Build the shared control plane before teams build ten separate token stores.
• Publish base policy as configuration.
• Give teams SDKs, templates, and self-service onboarding.
• Monitor for unregistered agent traffic.
• Treat agent permissions as delegated capabilities, not inherited user access.

Companion Skills Pack

We turned this architecture into a reusable starter pack in the AI Skills Guide.

The pack includes:

• security/ad-platform-agent-auth-review - review OAuth, service-account, token-storage, workspace-scoping, and read/write separation risks.
• agentops/ad-platform-policy-gate-designer - design approval thresholds, deny rules, bounded execution grants, and audit requirements.
• adtech/ad-platform-executor-template - define a narrow executor contract for approved DV360 and Google Ads writes.
• adtech/ad-platform-control-plane-supervisor - coordinate auth review, policy gates, executor readiness, audit, and rollback planning.

Use the hosted catalog to browse and download the pack. Engineers can inspect the source, fork it, or contribute improvements in the AI Skills Guide GitHub repository.

Reference Reading

Agentic Commerce and Delegated Authority

• Google Merchant Center Help: Agentic checkout and UCP
• Google Developers Blog: Under the hood of Universal Commerce Protocol
• Google Ads & Commerce Blog: Agentic commerce AI tools and protocols for retailers
• Google Cloud Blog: Agents to Payments Protocol
• Shopify Developer Docs: Build for agents
• Shopify News: AI commerce at scale
• Stripe: Agentic Commerce Suite
• Stripe: Giving agents the ability to pay

Google OAuth, Google Ads, and DV360 Implementation

• Google Identity: OAuth 2.0 scopes
• Google Identity: OAuth best practices
• Google Identity: OAuth app policies
• Google Ads API: Service account workflow
• Google Ads API: OAuth internals
• DV360 API: Targeting best practices
• DV360 API: Audience targeting

Security Background

• Curity: OAuth scope best practices
• Obsidian Security: OAuth scopes and permissions security best practices
• Patronum: Implementing least privilege in Google Workspace
• OneUptime: OAuth consent screen and least-privilege scopes in GCP

---

AI News Hub: translating frontier AI into actionable marketing playbooks.