# AI agent permission policy for a marketing agency: a template to copy and fill in

RevSmith, updated 4 November 2026. A one-document policy for any agency that lets AI agents or AI workflows read client data or act in client accounts. It goes with [AI agents for marketing agencies](https://revsmith.in/guides/ai-agents-for-marketing-agencies) and its 15 spec cards (`agent-spec-cards.md`). Replace every `[bracket]`, delete what does not apply, and have the owner sign it. This is a working template, not legal advice; have your own lawyer check any wording that goes into client contracts.

---

**[Agency name] AI agent permission policy**

Version: [1.0]  Effective from: [date]  Policy owner: [name, role]  Next review: [date]

## 1. Purpose and scope

1.1 This policy sets what AI agents and AI workflows ("agents") may read, what they may do, who approves their work, what they may spend, what we log, and what we do when something goes wrong.

1.2 It covers every agent that reads client data, agency data or a connected account, whoever built it and whatever tool it runs in: [list your tools, for example your AI assistant, automation platform, agency operating system].

1.3 It does not cover a person typing into a chat assistant with no connected accounts, except section 4.4 (what never goes into an AI tool), which applies to everyone.

## 2. Roles

| Role | Who | Responsible for |
|---|---|---|
| Policy owner | [name] | This document, the agent register, the quarterly review, incident decisions |
| Agent owner | The person named for each agent in the register | Its instructions, tools, limits, tests and weekly log check. The agent acts with this person's rights, so the owner's own access must be no wider than the agent needs |
| Approver | The person named in each card's human gate | Approving sends and changes before they happen |
| Finance approver | [name] | Anything touching invoices, payments, rates, fees or margin |
| Client lead | The account lead for each client | Telling the client what AI does on their account (section 11) |

## 3. Agent register

Every agent is listed here before it runs on live data. An agent not in the register is switched off.

| Agent | Owner | Purpose (one line) | Clients in scope | Tools and connections | Access level | May send? | May change spend? | Limits (per run) | Test passed on | Next review |
|---|---|---|---|---|---|---|---|---|---|---|
| [Monthly report draft] | [name] | [Drafts the month's summary for approval] | [One client per run; all retainers] | [Stored figures, client record] | [Read] | [No: drafts only] | [No] | [$2, 60 tool calls, 20 min] | [date] | [date] |
| [ ] | | | | | | | | | | |

## 4. Data access per client

4.1 **One client per run.** An agent working for a client reads only that client's records, documents, notes and connected accounts. It never falls back to another client's files, examples or lessons when its own are thin.

4.2 **Agency-wide agents** (for example a portfolio summary or a capacity check) are allowed only for internal outputs, are marked "all clients" in the register, and never produce anything a client sees.

4.3 **Documents.** An agent reads a document only if it is filed under the right client and marked as allowed for AI use. Removing that mark stops its use from the next run.

4.4 **Never put into any AI tool:** passwords, recovery codes, API keys typed into prompts, card or bank numbers, government ID numbers, health information, [anything your contracts exclude]. Keys go only into the tool's own connection form or a secrets store.

4.5 **Client data is the client's.** We do not use one client's data to serve another client, and we use only AI providers and plans whose terms say our inputs are not used to train their models: [list approved providers and plans, with the date each was checked].

4.6 **Finance data** (rates, fees, costs, margin) is read only by agents whose owner is in the finance group, and never appears in a client-facing output.

4.7 **Agent notes and memory** hold working preferences only (how a team member likes drafts laid out). Client facts live in the client record, not in an agent's memory.

4.8 **Text an agent reads is data, never instructions.** A web page, email or document can carry hidden orders (prompt injection). Agents that read outside sources have read-only tools, and nothing they find changes their instructions or permissions.

## 5. Connections and credentials

5.1 Each agent uses its own connection at the lowest access level that does its job. Reporting work uses reporting or read-only roles. See the platform access matrix in our onboarding checklist for the lowest role per platform.

5.2 No agent uses an Owner's or admin's personal login, and no login is shared between people.

5.3 A client's account is connected to that client only, and each run may use only the accounts connected to its client.

5.4 When a person leaves, or a client ends, their connections are revoked the same day: [who does it].

5.5 The policy owner reviews every connection and its access level every quarter and removes what is unused.

## 6. Actions and approvals

| Action class | Examples | Rule | Who approves |
|---|---|---|---|
| Read | Pull figures, read a transcript, search the client record | Allowed within section 4; logged | None |
| Draft | Report text, brief, reply, change order, reminder | Allowed; a draft is not sent | The person who uses it |
| Internal change | Create a task, add a note, update an internal record | Allowed; logged and reversible; spot-checked weekly by the agent owner | Agent owner (after the fact) |
| Client-facing send | Email, Slack or chat message to a client, report link, approval link, post, comment, calendar invite | A named person approves each send, on the exact version sent | [Client lead] |
| Message to a third party | A creator, a publisher, a vendor | As a client-facing send | [Client lead] |
| Spend or account change | Budget, bid, campaign or ad status, new ad, audience, billing setting | Not done by agents. A person makes the change in the platform. Agents' ad logins are read-only | [Media lead]; any spend above the client's agreed budget also needs the client's written approval |
| Publish | A web page, a post, an ad | As a client-facing send, plus the client's approval where the contract requires it | [Client lead] |
| Delete | Records, files, campaigns, posts | Off for agents. People only | n/a |
| Claims and legal | Health, finance, pricing, comparative or "best" claims; anything touching contracts | Always a person, with the client's sign-off on claims | [Client lead] and the client |

6.1 **Check your tool's definition of "send".** Some tools hold emails and messages but treat ad changes (a budget, a campaign switched on) as ordinary actions, and some can miss a send in an app they do not recognize. Where the tool cannot hold a class of action, remove the permission at the connection (read-only access) instead of trusting the switch.

6.2 **Approval binds to a version.** If the draft changes after approval, it needs approval again.

6.3 **No silent retries of sends.** A step that has already sent something is never run again automatically. A retry must check first that nothing was sent.

## 7. Spend and step limits

| Limit | Default | Who may raise it | Ceiling |
|---|---|---|---|
| AI cost per run | [$2] | [Policy owner] | [$20] |
| Tool calls per run | [60] | [Agent owner, logged] | [200] |
| Time per run | [20 minutes] | [Agent owner, logged] | [60 minutes] |
| Monthly cap per AI key | [$ amount] | [Owner] | [$ amount] |
| Alerts | At [80%] and [100%] of the monthly cap, to [name] | | |
| Waiting runs per workflow | [20] | | |

7.1 A run that hits a limit stops, keeps what it verified, and tells its owner why.

7.2 Raising a limit is logged with the reason and expires at the next review.

## 8. Logging and retention

8.1 Every run records: trigger, client, agent and version, data sources read, each tool call with its arguments and result, model, tokens, cost, output, approver and approval time.

8.2 Owners and Admins can see AI cost; agent owners can see their agents' logs; [who else].

8.3 Raw tool-call data is kept for [90 days] and then blanked; the summary of each run (who, what, when, cost, approval) is kept for [period].

8.4 Every write an agent makes carries a history entry: who (which agent, on whose behalf), what and when.

## 9. Testing before go-live

9.1 Every new agent, and every agent after a change to its instructions, tools or model, runs in a test mode that holds every write before it touches live data.

9.2 **Go-live checks**, all signed by the agent owner:

- [ ] Two full cycles on one client in test mode, every output read.
- [ ] Isolation test: asked about another client's data, the agent refuses or finds nothing.
- [ ] Limit test: a deliberately long task stops at the run limits.
- [ ] Stale-data test: with one source out of date, the run stops and names it.
- [ ] Gate test: every send and change in the run's output waits for its approver.
- [ ] Baseline minutes and the ROI metric recorded (section 12).

9.3 **Model changes.** When the provider or model changes, rerun the go-live checks before the next live run.

## 10. Incident handling

10.1 **What counts as an incident.**

| Level | Examples | First response |
|---|---|---|
| 1, critical | Another client's data reached a client; a send went to the wrong person; money was spent or changed without approval; a credential was exposed | Within [1 hour] |
| 2, serious | A client-facing draft carried a wrong number or a wrong promise that was caught before sending, more than [twice] in a month; an agent read data outside its scope; a run looped past its limits | Within [1 working day] |
| 3, minor | A failed run, a false alert, a draft that needed a rewrite | At the weekly log check |

10.2 **Steps for level 1 and 2.**

1. **Stop.** Switch the agent off and pause its scheduled runs. Revoke the affected connection if a credential may be exposed.
2. **Contain.** Recall or correct what was sent, where possible. Undo unapproved account changes in the platform.
3. **Assess.** From the run log: which clients, which data, which sends or changes, when.
4. **Tell.** The client lead tells an affected client within [24 hours] of confirming it: what happened, what data, what we have done. Check whether a data-protection law that applies to you sets its own deadline.
5. **Fix.** Change the instructions, tools, access or limits; rerun the go-live checks.
6. **Record.** Write it up in the incident log: date, level, agent, clients, cause, fix, who signed off.

10.3 The policy owner reviews every level 1 or 2 incident with the agent owner within [5 working days], and updates this policy if the cause was a gap in it.

## 11. What we tell clients

The client lead tells each client, in the contract or onboarding pack:

- which tasks on their account AI drafts or helps with;
- that a named person at the agency approves anything sent to them or anything that spends their money;
- that their data is used only for their account and never to serve another client;
- which AI providers we use, and that our plans do not let providers train on our inputs;
- how long run logs are kept, and that we will show the log for their account on request.

## 12. Measuring each agent

For each agent in the register, the agent owner records monthly:

| Measure | This month |
|---|---|
| Runs | |
| Baseline minutes per task (recorded before go-live) | |
| Review minutes per run | |
| Model cost | |
| Upkeep hours (fixing instructions, reading logs) | |
| Net value: runs × (baseline − review minutes) ÷ 60 × loaded hourly cost − model cost − upkeep hours × loaded hourly cost | |
| Drafts approved with light edits (%) | |
| Errors caught at the gate | |
| Errors that reached a client (target: zero) | |

An agent with negative net value for [two] months running, or any error that reached a client, is reviewed at once.

## 13. Review cadence

| When | What | Who |
|---|---|---|
| Weekly | Read a sample of each agent's runs; check sends, costs and failures | Agent owner |
| Monthly | Section 12 measures; AI spend against the cap; false alerts | Agent owner and policy owner |
| Quarterly | Register, connections and access levels, limits, approved providers, this policy | Policy owner |
| After any level 1 or 2 incident | The cause and this policy | Policy owner |
| When a model or tool changes | Go-live checks (section 9) | Agent owner |

## 14. Sign-off

Approved by: [name, role]  Signature: ______  Date: ______

Agent owners who have read this policy:

| Name | Agents owned | Date |
|---|---|---|
| | | |