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

An agent that can read an ad account can analyse performance and recommend a change. An agent that can write can alter bids, budgets, targeting, or published campaigns. The moment it can change a live account, the question is no longer only whether its recommendation is sensible. The system must also know which account is in scope, what the agent is allowed to change, who approved that change, and what actually reached the platform.

Consider a routine proposal: lower a line item’s bid because the cost per acquisition has risen. A connected Google account may have access to many advertisers. A token that lets software call an API proves that a platform credential was accepted; it does not prove that this particular bid change was approved, falls within the right client’s limits, or still matches the account state at execution time.

That is the design problem this guide addresses. Keep the model in the role of analyst and proposer. Put account access, policy decisions, approval, execution, and records in surrounding services with explicit boundaries. The useful pattern is a controlled path from read to proposal, authorization, execution, and verification.

Access is not approval

OAuth is a way for an application to obtain permission to call a service. The resulting access may be associated with a person or an application identity, and the platform applies its own roles and scopes. A refresh token can let an application request new access tokens without asking the person to sign in each time. None of these credentials, by themselves, express that a named person approved a specific campaign change.

Four decisions need to stay distinct:

Decision	Question it answers
Identity	Which person, application, or service is making the request?
Platform access	Which platform accounts and operations can that identity reach?
Internal authority	Which client, advertiser, campaign, and action does this workflow permit?
Approval	Who accepted this particular proposed change, under which limits and for how long?

Platform permissions cannot replace the organisation’s own client boundaries or approval rules. An API request may be valid according to Google while still violating an agency’s internal policy. A human may have approved a bid change while the current campaign state has since changed. The system must check both the approval and the conditions under which it was given.

The risk is not unique to a personal login. Service identities can also be over-scoped, leaked, or used outside their intended purpose. The goal is to give each part of the system only the authority it needs, then check that authority at the point of action.

Borrow the boundary, not the commerce protocol

Agentic commerce offers a useful design comparison. Shopping systems let agents search and prepare transactions while payment remains subject to a separate authority check. Google’s Universal Commerce Protocol and Agent Payments Protocol, Shopify’s agent flows, and Stripe’s commerce tools address commerce-specific tasks. They are not advertising standards and cannot be dropped into Google Ads or DV360 as an authorization system.

The transferable idea is narrower: an agent may prepare an action, while a separate service checks its scope and approval before carrying it out. For campaign operations, that means treating a bid or budget change as a bounded request, not as a consequence of the agent holding a broadly privileged account token.

Four trust zones around the same workflow

The responsibilities belong in different trust zones, even when a small implementation hosts several services together:

Zone	Responsibility and boundary
User identity and account connection	Establish who is connecting which account and who owns that connection; connection alone does not approve a campaign change
Control plane	Broker credentials, verify workspace and account mappings, evaluate policy, record approval, and issue or revoke bounded execution grants
Agent runtime	Read permitted evidence and prepare proposals; no standing platform write credential and no ability to issue its own grant
Executor	Validate the trusted grant and current state, obtain the needed platform credential, perform the bounded write, and verify its result

The executor is the write path; a read connector may use the broker for permitted retrieval without exposing a credential to the agent. Isolation and access controls must enforce these boundaries. Naming four services while letting the model runtime read all their secrets would preserve the diagram and defeat the architecture.

Follow one proposed change through the system

The architecture is easiest to assess as a sequence. Each step answers a different question and passes a limited record to the next.

1. Connect the account and keep credentials outside the model

A user or administrator connects an advertising account through the platform’s supported authorization flow. A broker stores the resulting credentials in a protected secret store and maps them to the organisation’s own workspace, advertiser, platform, environment, and owner. The broker can then make a narrowly scoped request for a particular operation without exposing long-lived credentials to the model.

OAuth scopes describe the broad access an application requests from a platform. Internal rules should narrow that further. If a workflow is meant to inspect one advertiser, the broker should not hand it an unrestricted credential simply because the connected user can reach several advertisers. Keep credentials out of prompts, model memory, ordinary logs, and tool responses.

Google Ads and DV360 document different ways to authorize API access, including service-account arrangements. A service account is an application identity rather than an employee’s login, but it still needs carefully assigned platform access and secure key handling. It does not automatically provide client-level isolation or approval for an individual change. Check the current requirements for the exact API, account setup, and operation before choosing an identity pattern.

2. Let the agent read and propose

The agent can inspect campaign state, performance, constraints, and relevant change history through read-only tools. It can then return a structured proposal that a service can inspect, compare with policy, and present for approval.

For example, a proposal could have this shape. These values are illustrative; they are not a real campaign report or a vendor API payload:

{
  "action": "propose_bid_change",
  "platform": "dv360",
  "advertiser_id": "987654",
  "line_item_id": "li_456",
  "current_bid": 1.2,
  "proposed_bid": 1.08,
  "change_percent": -10,
  "evidence_window": "2026-10-01/2026-10-07",
  "rationale": "Cost per acquisition rose while conversion volume stayed level.",
  "uncertainty": "Attribution delay may affect the latest two days."
}

This is a proposed change, not an instruction that the executor must obey. The model should not receive the credential used to apply it, and a field such as "requires_approval": false must not be allowed to bypass policy.

Structured proposals make differences visible. A reviewer can compare the requested value with the current value and the evidence behind it. They can also reject incomplete proposals rather than trying to infer the intended operation from conversational text.

3. Check policy and bind approval to the proposal

A policy service checks the proposal against explicit rules before any write is possible. It should verify the workspace and advertiser, the campaign object, the operation, the size and direction of the change, spend limits, targeting restrictions, relevant platform constraints, recent updates, and whether another change is already waiting for the same object.

Keep these rules in code or configuration that the organisation can inspect and change through a governed process. A prompt may ask the model to follow a policy, but it cannot enforce the policy. The model can explain its recommendation; it cannot grant itself permission.

Some changes may fit pre-approved bounds. Others should be blocked or sent to a person with the right responsibility. The table shows the kind of rule an organisation might define, not a recommended set of thresholds:

Example condition	Possible decision
Small bid change on an eligible, low-spend item	Allow only if that account and action are already in the approved scope
Larger bid change or a budget increase	Require approval from the responsible manager
Expansion into a sensitive audience or category	Block or route to a specialist review
Another update for the same item is already waiting	Queue or reject the new request until the first is resolved

Approval should identify the exact proposed change, account, limits, approver, and expiry. If the proposal changes after review, the approval should no longer apply. A broad approval for an entire account is difficult to interpret and harder to audit.

Thresholds are examples for an organisation to set, not universal safe values. A small bid adjustment may be high impact for one campaign and immaterial for another. Spend, audience sensitivity, market, legal obligations, and the ability to reverse the change all affect the decision.

4. Execute through a narrow service

The executor is the only component that can write to the ad platform. It receives the structured proposal and a short-lived internal grant that identifies the permitted account, object, operation, limits, and approval. It retrieves platform credentials from the broker, checks that the grant and approval are still valid, fetches the latest campaign state, and applies only the approved change.

The grant is a different record from the model’s proposal. For the bid-change example, a trusted internal service could issue a grant with this shape after the required checks. It is an application contract, not a Google API payload or a usable credential:

{
  "workspace_id": "client-123",
  "platform": "dv360",
  "advertiser_id": "987654",
  "entity_type": "line_item",
  "entity_id": "li_456",
  "allowed_action": "apply_bid_change",
  "approved_before": 1.2,
  "approved_after": 1.08,
  "max_delta_percent": 10,
  "proposal_ref": "proposal-42-v1",
  "approval_ref": "approval-42",
  "policy_version": "bid-policy-v3",
  "expires_at": "2026-10-24T18:00:00Z",
  "single_use": true
}

The executor must verify trusted issuance and integrity, resolve the references to immutable proposal and approval records, and check every bound. The percentage limits the permitted change; it does not authorize any other change inside that range. The exact approved before-and-after values still apply. The values and expiry above are examples, not recommended thresholds.

Pass the grant through the trusted control-plane-to-executor path. The model can receive proposal status without receiving a bearer credential or the power to mint one. Single use also needs durable enforcement: record an attempt before dispatch, and reconcile an uncertain platform response before any retry can repeat the effect.

If the campaign has changed since the proposal was reviewed, the executor should stop and request a new review instead of applying a stale change. Writes to the same campaign object should be serialized or otherwise protected against conflicting updates. After a write, the executor should read the platform state back and confirm what changed.

Some changes can be reversed directly; others have effects that cannot be undone, such as spend already incurred or impressions already served. Record a recovery or compensating action where a literal rollback is impossible. “Rollback available” should describe a tested capability, not a reassuring label attached to every change.

5. Keep a record that reconstructs the decision

For each attempted action, record enough to reconstruct the decision and its outcome:

Record	What it answers
Agent and model version; connected identity	Which system and credential initiated the request?
Workspace, advertiser, and current state	Which account was in scope, and what did it look like beforehand?
Proposal and supporting evidence	What change was requested, and why?
Policy result and approval	Which rule allowed, blocked, or escalated it, and who approved the exact change?
Scoped grant and API request	What authority was issued, and what did the executor send?
Platform response and verified after-state	What did the platform accept, and what changed in fact?
Recovery action	Was anything reversed, corrected, or left for follow-up?

Protect the record and define its retention because it can contain client and campaign information.

The record should let an operator answer: what did the agent see, what did it propose, what rule allowed or blocked it, who approved it, what request was sent, and what did the platform do? Store failures and denials as well as successful changes. An audit record should support investigation; replaying a write automatically can repeat the very effect being investigated.

Centralise the controls; keep the work close to the team

When several teams build agents against the same advertising accounts, each should not invent its own token store, approval format, and write path. Share the controls that define who can act and how actions are evidenced, while letting teams keep the analysis close to their work:

Shared by the organisation	Owned by product or channel teams
Credential broker and protected secret store	Campaign analysis, models, prompts, and workflows
Minimum rules for spend, targeting, data export, and approval	Read-only research and planning tools
Approval records and write-capable execution service	User experience and channel-specific integrations
Audit trail, revocation, and incident process	Stricter rules for a client, market, or category

Revocation has to follow the whole connection, not just its login screen. If an employee leaves or changes roles, reassess the connection owner, internal assignments, pending approvals, and outstanding grants. A platform token might remain technically valid while internal authority has ended. Expired or revoked grants must fail at execution, and ownership transfer should not silently transfer approval for queued changes. Test that stopping a workflow also stops its pending writes.

The shared service should enforce a common minimum and make policy failures understandable. If secure onboarding is slow or unclear, teams may create workarounds with personal credentials.

Centralization has its own risks. A shared broker or executor becomes a high-value target and a possible single point of failure. Separate clients and environments in its data model, restrict its administrators, monitor access, test revocation and recovery, and avoid giving the central service broad standing permission when a short-lived grant will do.

Test the boundaries against likely failures

Failure	What should stop or limit it
A connected identity reaches the wrong advertiser	Check workspace-to-advertiser mapping at proposal and execution time; do not rely on the model to choose the right account.
Text in a campaign name, landing page, or feed tries to redirect the agent	Treat retrieved text as untrusted; keep tools read-only during reasoning; enforce writes through policy and approval.
Two processes change the same campaign object	Check current state immediately before writing, serialize conflicting writes, and verify the resulting state.
A proposal expands spend or targeting too far	Apply explicit limits, deny rules, and stronger approval for high-impact changes; monitor after execution.
A token or key enters a prompt or log	Keep secrets in a protected store, retrieve them only in the executor, and redact operational logs.
Teams bypass the shared process	Make the approved route quick to register and use; monitor platform access and investigate unregistered integrations.

These controls reduce exposure; they do not make a marketing agent risk-free. A policy can encode the wrong rule. An approval can be mistaken. A platform may accept a request and later process it differently than expected. Operators need monitoring, revocation, incident handling, and a way to stop further writes.

Build in stages

Start by listing every agent and automation that can read or change Google Ads, DV360, or connected systems. Identify which identities they use, which accounts those identities can reach, where credentials are stored, and whether any workflow can write directly from the model runtime.

Then move one workflow at a time through these stages:

Read only: connect a defined account and validate the data the agent can retrieve.
Proposal only: return a structured change and show it beside the current state; do not write.
Policy and approval: enforce account, action, limit, and approval rules in a service outside the model.
Bounded execution: enable a narrow class of low-risk changes with strict limits and a tested stop path.
Review and expand: inspect denied and successful requests, errors, stale proposals, and recovery results before widening scope.

Keep human review for actions whose likely impact, uncertainty, or reversibility warrants it. Automation should grow from observed performance and explicit operating rules, not from one persuasive recommendation.

Platform details and limits

The architecture above is a reference design, not a guarantee that every platform exposes identical controls. Google Ads documents both user OAuth and service-account access, with account access and developer-token requirements. DV360 uses OAuth and documents service accounts associated with DV360 users as well as delegated arrangements. The exact roles, setup, and supported operations differ, so the broker must accommodate each platform rather than pretending one credential flow fits all.

Commerce protocols remain comparisons, not ad-tech authorization standards. Approval gates add time and require clear ownership. The organisation must decide who maintains spend limits, sensitive-category rules, approval responsibilities, incident response, and credential revocation. A control plane without an owner becomes another system people route around.

Companion material

The AI Skills Guide repository provides four related entry points, checked against its source on 24 October 2026:

Authentication review skill: inspect the credential chain, account scope, secret handling, and read/write separation.
Policy-gate design skill: specify action limits, approval responsibilities, deny rules, and audit evidence.
Executor tool contract: inspect the bounded change plan, grant checks, current-state precondition, verified receipt, and reconciliation path.
Control-plane supervisor template: coordinate a readiness review. Its documented role is advisory; it cannot approve changes or grant credentials.

The first two are skills, the third is a tool contract, and the fourth is an agent template. Treat them as starting points for implementation and review. Checking that these files exist does not establish that a deployment is secure or that its controls have passed testing. The simplified grant above is explanatory and does not substitute for the executor’s current contract.

References

Agentic commerce as a comparison

Platform authorization and operation

Security background

The model may find a useful campaign change. Reliability comes from the path around it: the right identity, the right account, a valid approval, a bounded executor, and a record that shows what happened. Give the model room to analyse and propose. Keep authority explicit at every step where a proposal can affect a live campaign.

Publication history

Originally published by Performics Labs.