AI agent permissions for clubs: how much access should you give?

Your club has already had the hard conversation and come out the other side: yes, we will let an AI agent work on the club platform. The question that decides whether it goes well is smaller, more practical, and much easier to get wrong — how much rope do you give it, and how do you decide?

That is a governance question rather than a technical one, and in ClubHelix it has a concrete answer. Creating a connection for an AI agent sets two dials. The first is the scope: read, allow changes, allow publishing. The second is a narrowing most clubs never open, which limits one connection to a subset of the admin — the news page without the shop, say. Get both right and your committee has something it can minute, review at a set date, and withdraw in one click.

This guide is about those two dials. It is not the setup walkthrough: connecting an AI assistant to your club data covers creating the connection and pasting the command. It is not the vendor checklist either — the questions to ask an AI provider before you trust it with member information live in AI safety and privacy for clubs. This one picks up after both, at the moment somebody is looking at the form and wondering which boxes to tick.

Where the dials live

In your club admin, open System → API & webhooks and find the card headed AI assistant access (MCP). It is available on every plan, including the free one — see pricing for what else each one includes. One scope decision is made for you and cannot be ticked on: no token can change your subscription, billing or payment settings, whatever its owner is allowed to do in the admin. Those are platform-staff tools. Creating a connection there mints a token: a long secret string that an AI agent presents on every request, the way a key card identifies a person at the door.

The form is short. Give the connection a name that says where it lives ("Claude on the secretary's laptop"), choose when it expires, tick or leave the two scope checkboxes, and optionally open Limit what this token can touch (optional) to narrow it further. That is the whole decision.

One thing to know before you start ticking: a connection acts as the person who created it. It is not a new account with powers of its own — it inherits that person's role and permissions and is re-checked against them on every request.

Dial one: read, change, or publish

Two checkboxes give you three scopes. They stack: leaving both off is the smallest, ticking the first adds to it, ticking both adds again.

Read only — leave both boxes off

This is where every club should start, and it is far from a token gesture. A read-only connection unlocks roughly 86 tools that work against your organisation's own data, covering members, money, events, fixtures, forms, facilities, programs, email and message deliverability, governance records, and the club's own audit log.

In practice it answers the questions your committee currently answers by exporting three spreadsheets and squinting. How many members have not renewed since the season opened? Which events sold fewest places last year, and on which nights? What changed on our website in the last fortnight, and who changed it? Did our last broadcast actually reach people, or did a chunk of it bounce?

Two properties make this safe enough to approve in a single meeting. First, the member-data tools return aggregates — counts by status and payment standing — rather than names, email addresses or medical details. An agent can tell you that forty-one members are unpaid; it cannot hand you the list of who they are. Second, reads are audited. They land in your club's audit log under the real person the connection acts as, so "what has this thing been looking at?" is a question with an answer rather than a shrug.

The honest limit is that read-only cannot do anything for you: it will tell you the newsletter is overdue and it will not write it. For most committees a month of exactly that is time well spent, because it turns an abstract argument about AI into a concrete list of jobs the club would like done.

Allow changes (create and edit pages, news, events)

Tick this and the agent can start producing work. It can create and edit pages, news posts and events, and it can adjust configuration such as your theme, navigation and settings.

What it cannot do is change what is on your site and what is not. Publishing and unpublishing both need the other box, so this scope can never put something new in front of your visitors or take something down, and that is enforced by the platform rather than by the agent's good manners. A new page is created as a draft no visitor can reach. On your website's pages the platform goes further still: rewriting one that is already live would change what visitors see immediately, so a change-only connection is refused outright and pointed at the draft instead.

Be precise about the edge, because it is the one thing committees get wrong here. This scope can correct the wording of a news post or an event that is already on the public site — those tools deliberately leave the status alone, so a live post stays live and its words change. That is usually exactly what you want from a drafting agent, and it is not the same promise as "nothing it does is visible". The promise you actually made by ticking one box and not the other is that the agent cannot decide what is published.

There is a second brake. Every change dry-runs first: the agent's opening call gets back a description of what would happen, and nothing is written until it comes back with an explicit confirmation. So the shape of a session is always the agent proposes, a person reads the proposal, a person says go. That review step happens whether or not anyone thought to ask for one.

Allow publishing (make changes visible to the public)

This is additive on top of changes, so ticking it gives you both. Now the agent can take the draft it wrote and make it live — and, just as importantly, take something down again or roll it back to an earlier version. A publish-scoped connection is a repair tool as well as a risk.

It is a narrower power than it sounds, and this is the sentence worth carrying into the meeting: a publish-scoped agent can put a page live, and still cannot send a single email to a member. There are more than 200 tools in the whole endpoint and not one of them sends an email or an SMS, takes a payment, or issues a refund. The messaging tools that exist are delivery reports, suppression lists and configuration readouts. An agent can draft a broadcast; a human being presses send. That line is drawn in the product, not in your policy document, so nobody has to remember it.

Dial two: limit what this token can touch

Under the checkboxes sits a collapsed section headed Limit what this token can touch (optional). Most clubs never open it, and it is the dial that does the most to make a bolder scope comfortable. Its own on-screen explanation is the clearest version: "Tick nothing and the token can do everything you can do. Tick some and it can do only those things."

Inside is a checkbox per permission, grouped the way your admin is grouped. So you can mint a connection that may write news posts and nothing else — not the shop, not the member roster, not the payment settings — even though the person who created it reaches all of those every day.

The rule that makes this trustworthy is an intersection, and it runs in one direction only. Narrowing can never add capability. A connection's real power is the overlap between what its owner may do and what you ticked. If the owner is a moderator, it is a moderator's connection however generously you tick. If you narrow it to news, it is a news connection even though its owner runs the whole organisation. And if the owner's permissions change next month, the connection changes with them — the check runs live on every request rather than being frozen when the token was minted.

The practical read: decide the scope by the job, not by the person. The secretary may well be entitled to everything. The job you are handing the agent is "keep the news page current", so tick news.

A staged ladder your committee can vote on

Here is the motion. Three stages, each with something to try, something to check afterwards, and a clear trigger for stepping back. Move up a rung per meeting, or sit on one indefinitely — staying at stage one forever is a perfectly respectable outcome.

Stage one — a month of read only

What to try. One connection, both boxes off, expiring in 90 days. Ask it the questions your committee actually argues about: who has not renewed, which events under-sold, what changed on the site last month, whether the last broadcast landed. Keep a shared note of which questions produced something useful.

What to check afterwards. Open the audit log and look at the activity recorded under the owner's name. Does the volume match the work you asked for? Did anyone else borrow the connection informally? Was any answer wrong in a way that mattered, and did somebody notice?

What would make you step back. Confident answers that turn out to be wrong, with nobody checking. The problem then is not the scope — it is that nothing in your process verifies what the agent says, and a wider scope would only compound it.

Stage two — changes on, publishing off

What to try. Mint a connection with Allow changes ticked and Allow publishing left off, narrowed to one area — news, or events. Give it a real job with a deadline: draft the three match reports before Thursday, or build the draft page for the junior sign-up season.

What to check afterwards. Read what it proposed before anybody confirmed anything. The dry-run step means there is always a plan to read; the question is whether a person genuinely read it or clicked through. Then judge the drafts as a reader would: is the tone yours, are the dates right, has it invented a detail nobody gave it?

What would make you step back. Drafts arriving faster than anyone can review them. That is the failure mode here — not a rogue agent, but a queue of plausible work waved through because reviewing it properly takes longer than writing it did.

Stage three — publishing, on one narrow area

What to try. One connection, publishing on, narrowed to the single area where the stage-two review habit is strongest. Most clubs land on news, because a news post is the lowest-stakes thing on a club website and the easiest to fix in public.

What to check afterwards. Compare the live site against what the committee expected to be live. Check somebody still reads the audit log monthly. Confirm the areas you did not open are still closed — a narrowed connection is only as good as its narrowing, so re-read the ticks.

What would make you step back. Anything going live the committee had not agreed to, even once. The remedy is not a lecture; it is to revoke the connection and re-mint it one rung down, which takes about a minute.

The governance wrapper

Scope is the decision. The wrapper is what keeps that decision reviewable six months later, when the person who made it has rotated off the committee.

Name an owner, and say so out loud

A connection acts as one person. Choose someone accountable — secretary or registrar is the usual answer, and if your committee has never written down who holds what, club committee roles and responsibilities is the place to start. The audit log records the agent's activity under that person's name, which is a feature rather than an accident: there is always a human answerable for what the connection did.

It also inherits their limits. And because the privilege check runs live, the day that person stops being an admin the connection stops working, without anybody having to remember. Revoke it anyway — a connection nobody owns is a connection nobody reviews.

Treat expiry as a review trigger, not a chore

The form offers 30 days, 90 days, 1 year, or Never, and defaults to 90 days. Take the default. Ninety days is roughly a committee cycle, which turns a security setting into something more useful: a standing agenda item that asks "is this still doing what we approved?" four times a year.

"Never" is the option that quietly outlives the committee that chose it. If you do pick a long expiry, put the review in the calendar yourself — the alternative is a working key to your club platform sitting on a laptop that left the club two seasons ago.

Revocation is the real safety net

One click ends a connection everywhere, immediately: the answer to a lost laptop, a finished project, a volunteer moving on, or a committee that has changed its mind. Re-minting takes a minute, so there is no reason to hesitate — revoke first, discuss after. Treat it the way you treat the clubhouse padlock code when somebody hands back their key.

The honest note about two-step sign-in

One limit deserves stating plainly rather than being buried. A connection token bypasses the two-step verification prompt a person gets when signing in through a browser. That is how every API credential works — the token is the credential, so there is no second step to ask for. It is exactly why the other three controls matter: the token expires, it is revocable in one click, and everything it does is audited under a named person. Do not let any of the three slide.

One more limit worth minuting honestly: the connection is rate-limited at 120 requests a minute, so a runaway agent meets a wall rather than your whole database.

What to write in the minutes

Keep it to five lines. A motion this short is one a future committee can act on:

1. What was approved — "an AI agent connection to the club platform at read-only scope", or "changes, narrowed to news, publishing off".
2. Who owns it — the named person, and the fact that the audit log records the agent's activity under their name.
3. When it expires — the date, and who re-mints it.
4. When it is reviewed — the meeting at which the committee looks at the audit log and decides whether to move up, stay, or step back.
5. Who may revoke it — ideally any committee member, without needing a meeting.

That is a policy. It fits on a page, it names a person, and it has a date on it — more than most technology decisions get.

Frequently asked questions

Can an AI agent delete our members or take their money?

No. Nothing in the connection sends an email or an SMS, takes a payment, or issues a refund — those tools do not exist, so they cannot be asked for. Member information comes back as aggregate counts rather than names or contact details, and every change is permission-checked against what the owner may do, dry-run before it is written, and recorded in the audit log.

Should we give one connection to the whole committee, or one each?

One each, named after where it lives. Connections are cheap to create and free to revoke, and a shared secret is one nobody is accountable for. Separate connections also keep the audit log readable: when two people are working with agents, you want to tell whose did what. And if two jobs need different scopes — read-only for the treasurer, news-only for the communications volunteer — that is two connections, not one compromise.

What if the agent does something we did not expect?

Revoke the connection first; one click stops everything immediately. Then read the audit log, which records what happened under the owner's name. If the agent published something, page history is kept, so an earlier version can be restored. Then decide whether the scope was wrong, the narrowing too generous, or the review habit slipped — and re-mint one rung down the ladder while you work it out.

Do we need to understand the technology to approve this?

No more than you need to understand door locks to decide who gets a key. The useful model is that the platform publishes a fixed menu of things an agent may ask for and refuses everything else; your two dials decide how much of that menu this connection can see. For the mechanics, the integrations and AI agent access pages describe how the connection is built, and our security page covers the platform controls underneath it.

How do we know an agent is not reaching another club's data?

The connection is pinned to your organisation when it is created. Tools that work across the platform refuse it outright, tools that take an organisation name refuse any name but yours, and the database itself is the last line, filtering rows to your organisation regardless of what the application asks for. Three separate refusals rather than one setting — because a control resting on a single check has a single point of failure.