Most marketing AI access policies answer one question: who can sign in?

Production work needs several other answers:

Who can submit a request?
Who can provide the source material?
Who can approve a claim?
Who can publish the asset?
Who can see customer or confidential data?
Who can stop or revoke the process when the assignment ends?

A seat is an identity. It is not permission to approve, publish, or access every source.

Treat those actions separately and the policy becomes easier to explain, review, and change.

Separate the roles#

Start with a small role map:

Role	May do	May not do by default
Requester	Create a brief and submit approved sources	Approve own customer-facing claims
Source owner	Maintain current facts and evidence	Publish an asset without the content path
Content owner	Draft, repair, and respond to returns	Change a product fact without its owner
Approver	Accept or return within a stated scope	Approve a different audience or channel
Publisher	Move approved work to the destination	Change approved claims silently
Finance owner	See allocation and budget outcome	Read source content not needed for reconciliation
Security or IT	Manage provider access and data boundaries	Make marketing acceptance decisions

One person can hold several roles in a small team. The decisions should still be distinct. When the same person requests, approves, and publishes high-impact work, record that combination and set a review rule for it.

Narrow access by data and action#

The relevant boundary is not “marketing has access.” It is:

which project or campaign the person can see;
which source collections can be used;
which provider or model may receive the data;
which channels may receive the output;
which approval scopes the person can accept;
how long the access remains valid.

An agency copywriter may need campaign notes and approved product facts. They may not need the customer export, internal security notes, or publishing credentials. A tool that drafts copy may not need the ability to send a message or publish a page.

The service-account permissions guide explains why one broad identity makes agent actions difficult to attribute. Marketing workflows have the same issue: a shared login turns a person, tool, campaign, and approval into one blurry principal.

Use a short access lifecycle#

For every person and tool, record:

who requested access;
what campaign or process needs it;
which data and actions are included;
who approved the boundary;
when it expires or gets reviewed;
how access is revoked;
what happens to assets and evidence after revocation.

Project access should have an end date. If the campaign continues, renew it with the same owner and a fresh scope. Do not let a temporary agency assignment become a permanent key because no one remembered to close it.

Keep approval authority separate from tool access#

A person who can use a drafting tool does not automatically have authority to approve its output. A person who can view a product source does not automatically have authority to change the source. A publisher should receive an approved asset with a bounded decision, not a request to decide whether the content seems safe.

This separation helps during review:

Question	Evidence
Who requested the asset?	Brief owner and identity
Which data did the tool receive?	Source IDs and data boundary
Who accepted the claim?	Approver, scope, and date
Who published it?	Publisher identity and destination
Could access still be used later?	Expiry or revocation record

Handle exceptions explicitly#

Urgent work will sometimes need a person to hold two roles or use a source outside the normal collection. Record the exception instead of making the policy vague for everyone:

asset and campaign;
temporary access or combined role;
approver who accepted the scope;
end date;
source and channel limits;
follow-up required before another asset uses the path.

The exception queue guide gives this decision a place to live. An exception that has an owner and expiry is manageable. An exception hidden inside a shared password is not.

Review access using work outcomes#

Once a month, find:

accounts with no accepted or published work;
tools that received data outside their campaign boundary;
approvals made outside the person’s stated scope;
access that passed its project end date;
assets with no named approver or publisher;
shared identities that prevent attribution.

This is a better review than counting seats. It connects identity to the work and the decision that identity was allowed to make.

Marketing needs speed, but speed does not require a shared identity with broad permissions. A clear role map, narrow data boundary, short lifecycle, and named approval authority let the team move quickly without making every future review a forensic exercise.