What to demand before an agent touches your inbox or ad accounts | APX Digital

What to demand before an agent touches your inbox or ad accounts

An agent that can send email, move money or run ad spend holds the same keys as an employee, so it needs the same contract, access list and off switch. We run agents on our own marketing daily (the full walkthrough is here), so this list is not theory: every item is a fence we built for ourselves before anything went near a live account.

Work down it with your supplier on the call. Ten yeses means you can start; below eight, the gaps are the risks you are accepting.

The ten demands

1. Least privilege, in writing, per system. The agent gets the narrowest permission that does the job: inbox read-and-draft, not send-as-you. On an ad account, the Advertiser role (create and edit ads), never Admin, which per Meta's own role table can change the payment method and add or remove other people's access. The UK National Cyber Security Centre's 10 Steps guidance tells organisations to use full-privilege accounts "only when absolutely necessary" and to review access regularly, revoking privileges when no longer required, a rule written for human admins that fits agents even better, since they never get bored and share passwords. Ask the supplier to name exactly which scopes the agent holds on each of your systems.
2. Credentials the agent can use but never read. In our pipeline, the push scripts fetch the page token from the macOS Keychain at run time. The agent's only path to Facebook is a script that already holds the key. It cannot print, copy, or leak a secret it was never given. "I put the API key in the prompt" is how accounts get burned.
3. A staging area, default-on. Nothing the agent writes goes live until it has sat somewhere reversible first: a drafts folder, a review queue. Our pipeline cannot post at all unless the output has passed through a dated draft directory with a manifest. If a system has no staging mode, it is not production-grade.
4. A kill-switch a human can pull in under a minute. Not "contact support for deactivation". Revoke the token, flip the config field, close the app. Ours is partly the credential itself: with no page ID and no Keychain token, the pipeline runs and publishes nothing. Demand a switch you control, and test it before go-live, while you're calm.
5. A named human on the loop, and a job description for the loop. Someone reads what the agent reports, not just what it posts. Our agent writes a five-line brief to the owner every day: what ran, what failed, what it needs from him. Ask what the agent will report to you, how often, and what happens when nobody reads it (correct answer: publishing stops, it doesn't proceed anyway).
6. A QA gate that can fail the work. Our renders go back to a QA step that can reject them, twice, before a fallback kicks in and says so. An agent that grades its own homework with a rubber stamp is decorating the risk. Ask what the automated check actually tests, and what happened the last time it failed something.
7. A log with dates you can audit. Every run appends a machine-readable line: entry used, assets, QA result, published status. "It should've done about six posts last month" is not a reporting standard. If the supplier can't show you their own history file, they don't have one.
8. Explicit "never" rules in the contract. Our playbook bans invented claims and competitor-bashing copy outright, and pointedly auto-publishing until credentials are deliberately added. Write down the actions the agent must never take unilaterally: refunds, cancellations, price quotes, statements of legal fact, spending above zero.
9. A test path before the live path. Sandboxes, staging ad accounts, a dummy inbox. Our blog pipeline's publishing posture is the same lesson: it has run against the real repo with the real design system, and the last mile stays manually wired shut. Ask to watch the agent fail safely before you watch it succeed on live data.
10. A security framework named, not waved at. OWASP's Top 10 for Agentic Applications 2026 spends its list on things like goal hijack (ASI01) and identity and privilege abuse (ASI03), which is a plain-language way of saying: the content your agent reads can attack it, and its permissions are the blast radius. A supplier who has read something recent can tell you which of those risks their design addresses and which they're accepting on your behalf.

Two questions that sort the industry instantly

"What can the agent not do on day one?" A serious builder answers fast; the list is the specification. And: "Show me your own kill-switch." We answered that one with file paths.

Then the commercial fence, same as any supplier: fixed scope, deposit-and-balance terms, and an offboarding clause that says who keeps the configs, the logs and the credentials when you leave. If the agent runs your inbox, its accounts are yours; get that in writing before anyone types a password.

The background on what actually counts as an agentic system (versus a chatbot with a press release) is in What an agentic system is (and is not).

Getting an agent near your accounts? That's the point where a boring, auditable build beats a slick demo. APX: chatbots from £397 (Basic; Advanced £797, Enterprise £1,497, support from £50/mo, apxdigital.io/ai-chatbots); agentic systems quoted on scope. Info@apxdigital.io · 07753 226214 · Birmingham / Coventry / West Midlands.