What Access Should an AI Agent Have? A Day-One Checklist

What access should an AI agent have? Start read-only wherever the tool allows it. Grant write access only for the one action a task actually needs. Withhold anything with billing, admin, or bulk-delete power. Expand access in stages once the agent proves itself, rather than granting broad scope up front.

What Access Should an AI Agent Have? The Short Answer

That's the practical answer. Here's the part most guides skip: telling your agent not to do something, and it being unable to do it, are two completely different things. One lives in the prompt. The other lives in the account. Mix them up, and a narrow task quietly turns into a wide-open one.

Below, you'll find a Day-One Access Checklist by app category (email, calendar, CRM, invoicing, files, marketing), plus a Grant / Read-Only / Withhold table you can run against your own connector screen in about ten minutes.

A Prompt Is Not a Permission

Here's the case that proves it, and it's not a small one. PocketOS sells software car rental businesses rely on for reservations and vehicle assignments. According to founder Jeremy Crane, it took nine seconds for an AI coding agent to delete the company's entire production database and its backups (The Guardian, 2026-04-29). That figure is Crane's own account, not an audited log. Don't read it as a Cursor or Claude reliability benchmark. Read it as what nine seconds of unsupervised write access can do.

The agent was Cursor, running Anthropic's Claude Opus 4.6, with an explicit system rule: “NEVER run destructive/irreversible git commands... unless the user explicitly requests them.” It ran one anyway, then confessed: “I violated every principle I was given.” Crane: “the agent didn't just fail safety. It explained, in writing, exactly which safety rules it ignored.” Real customers were locked out of the software managing their bookings as a result.

n8n's own account of the same incident (2026-08-27) makes the mechanism point: “allowing agents to enforce their own security rules makes them vulnerable to prompt injection attacks.” The rule lived in the prompt. Nothing at the account level stopped the delete. Yes, n8n sells the platform proposing the fix, so take the pitch with a grain of salt, but the mechanism it's describing checks out regardless.

There's also a difference between this and any employee who ignores a written policy. An agent can be prompt-injected into breaking its own rule, it can misread an ambiguous instruction as permission it was never given, and it can act on a whole database in nine seconds, the exact timescale from PocketOS's case, before anyone gets the chance to ask it to explain itself first.

Written rules fail for humans too, not just agents. In a Zapier-commissioned survey of 548 US executives at 500-plus-employee companies, 79% said employees route around AI governance policies despite 91% having formal ones on paper (Zapier/Centiment, 2026-08-17). That's a sample with its own compliance department, and the written rule still didn't hold. You don't have a compliance department.

None of this means instructions don't matter. Getting them right is a different problem, one for a different article. This one is about whether the account itself can still do the damage after an instruction fails.

Read vs Write: The One Distinction Most Guides Skip

“Grant only the permissions the agent needs for that task. Nothing more.” (X, @v_shakthi, 2026-04-03)

Read access lets an agent see something: an inbox, an invoice, a CRM record. Write access lets it change something: send an email, issue a refund, delete a record. That's the whole distinction, and almost every automation a non-coder builds can run on read-only, or read plus one narrow write action. It doesn't need broad write access on day one. Almost nothing does.

If a task seems to need broad write access before you've watched it run even once, treat that as a signal to scope it further, not a reason to grant it. n8n frames its own escalation ladder this way: a fixed step runs exactly what you built, a tool the agent calls still does the action you defined ahead of time, and only an open-ended connection lets it decide what happens next (n8n, 2026-08-10). Simple rule: the more a task tilts toward “the agent decides,” the more it deserves read-only first.

The Day-One Access Checklist, by App Category

For each account you connect, here's the default to start with, and the one thing worth checking before you grant more.

Email and calendar

Read-only (inbox, calendar) covers most triage and summarization. A daily digest doesn't need send access. Write access (send, delete, forward) should scope to the one action the task needs. For “draft replies,” have it hand you the draft first, always. Viewing your schedule is read. Moving other people's meetings is write, and a much bigger deal.

CRM and contacts

Read access covers reports and drafting follow-ups, which is most of what a non-coder automates in a CRM. Editing records, bulk updates, and deleting contacts are the highest-risk write scope here, because a CRM usually holds your entire customer relationship. Keep it narrow. Prefer reversible actions.

Invoicing and payments

Read-only covers almost every invoicing task. Anything that moves money, issues a refund, or changes a payment method is the scope to withhold longest. Gemini Spark checks in with you “before doing anything sensitive, like sending an email or making a purchase” (Zapier, 2026-08-24, quoting Google). Binance confines its own AI trading agents to a subaccount with withdrawals blocked by default (TechCrunch, 2026-08-20). That's a crypto example, not financial advice, but the pattern translates: give the agent its own limited login for anything touching money.

Files and storage

No documented case exists here. It's a judgement call on the same logic: scope read and write to the folder the task touches, not the whole drive.

Marketing and social

Same caveat as above: no documented case, just read-before-write applied plainly. Read access for drafting is low-risk. Publish access stays back until you trust its pattern.

If you'd rather get this kind of breakdown before your next connector screen, that's what our newsletter is for.

Grant / Read-Only / Withhold: The Decision Table

The pattern across every row is the same: read before write, narrow before broad, reversible before irreversible.

Accounts You Should Never Connect First

Whatever the task, withhold these entirely on day one, no exceptions:

• Billing or admin rights across your whole workspace. An agent that can add users or touch billing can do damage far outside whatever task you actually asked it to do.
• Anything that moves money without a second check that a human actively approves. A warning box you click past doesn't count.
• Bulk-delete or bulk-export on your full customer or financial data. A bad instruction, or a prompt-injected one, shouldn't be able to touch every record you own.
• Your production database, or whatever your business's equivalent is. This is the PocketOS category: n8n's account of that incident notes the agent “had broad, root-level permissions” (n8n, 2026-08-27), exactly what let nine seconds become the whole database.

This list exists for one reason: if something goes wrong, you want the damage to be a mistake you can undo, not one you can't. A smaller version of the same failure: @DataChaz found an unscoped Railway CLI token just sitting around (X, 2026-04-27). Nobody decided to grant broad access. The credential just quietly carried more power than anyone meant it to.

Who's actually on the hook when this goes wrong is a separate question, and it's worth reading on its own.

What Your Tools Actually Let You Control

Everything below is documented behavior from each vendor's own pages, sourced as we go. None of it is the product of any internal test on our end. (Unclear what MCP actually is? Worth a quick detour first.)

Claude for Small Business

Connectors authenticate through your existing app logins, so whatever access you already have carries straight through: “if an employee can't see something in QuickBooks today, they can't see it through Claude” ( Zapier, 2026-08-24). The permission ceiling is whatever your app account already allows, nothing more. It connects with 10-plus named apps (QuickBooks, PayPal, HubSpot, Canva, Docusign, Google Workspace, Microsoft 365) and comes included in Claude Pro ($20 a month).

Gemini Spark

Spark “checks in with you before doing anything sensitive, like sending an email or making a purchase,” and otherwise runs on its own (Zapier, updated 2026-08-24, quoting Google), whose own docs state “you're responsible for supervising each MCP server.” Worth flagging: the Zapier author says Spark is only available in certain countries and that they haven't tested it themselves. So treat every Spark claim here as documented, not observed. Connected apps also won't work unless you turn on “Keep Activity,” a retention setting of 3, 18, or 36 months, a privacy decision worth making on purpose.

Agent skills, plug-ins, and MCPs are unsigned code

Skills, plug-ins, and MCPs load code the same way a driver loads code into your kernel, except nobody checks a signature here. AIR co-founder Yair Saban: “whenever you installed a driver, the driver didn't need to be signed... it's the same mechanism, the same lesson, but we haven't learned it” (TechCrunch, 2026-09-01). AIR raised $50 million to build a vetting layer for this. Its own figure, filtering “about 27% of the add-ons and skills it finds online,” is AIR's own number about its own filter, with no published methodology behind it. Treat it as a vendor claim about AIR's filter, never as “27% of skills are malicious.”

Two independent data points worth having on hand: Anthropic's developer docs describe “always_allow” and “always_ask” permission policies (the agent toolset defaults to always_allow, MCP toolsets default to always_ask). OpenAI's developer docs require approval before data is shared with a connector by default. Both are account-level controls, not prompt-level requests, which is the whole point of this article.

Skip This (For Now) If You Can't Answer These

Before you flip a workflow live, answer three questions honestly:

• Do you know exactly which accounts this agent can touch?
• Is write access limited to the one action the task actually needs?
• If the agent did the worst thing it's capable of with its current access, could you undo it?

If the honest answer to any of those is no, narrow the scope further. Don't hope the prompt catches it, because it won't. As Gergely Orosz put it, in a different context: “the blame sits with the dev who decided to delegate decision making” (X, 2026-04-27). True whether “dev” means an engineer, or you, deciding what to connect on a Tuesday afternoon. It isn't unique to agents, either: “giving someone too permissive access and having them operate under mid to high stress” (@clairevo, X, 2026-04-27) describes most people's first week with a new AI tool too.

What Access Should an AI Agent Have: FAQ

Who should have access to AI? Anyone using an AI agent should have access scoped to their own job, not the whole organization by default. The agent gets exactly the accounts and actions its task needs, nothing wider.

How do I secure AI agent access?Start read-only, add write access only for the one action the task needs, and keep anything that moves money, deletes in bulk, or touches a production system out of reach on day one. Then confirm the account itself enforces that; a written instruction not to do something isn't the same as being unable to.

What does an AI agent need? Exactly the accounts and permissions its task requires, and almost nothing more. Most non-coder automations run fine on read-only, or read plus one narrow write action.

How do you access an AI agent? Most no-code agents, through Zapier, Make, n8n, Claude, or Gemini, are accessed through the login and connector setup you already use for those platforms; you authorize its access one connector at a time.

The Short Version (and What to Set Up Next)

For the wider picture: the broader safety picture for a small team is covered separately, and getting the instructions right is its own piece, the complement to everything above. Before any of this goes live, test the workflow at its narrow scope first, regardless of how confident you feel about it.

If you want this kind of concrete, no-vendor-spin breakdown before your next connector screen, that's what our newsletter is for.