Agent access

Tidewater’s marketing team want to draft posts from Claude, and the developer wants to fix a typo from a terminal without opening the Control Plane. Agent access is how a site allows that, and how an administrator keeps it narrow.

After reading this guide, you will know:

• What a connected app can and can’t do, and why it can never do more than the person who connected it.
• How to turn agent access on, and choose what apps may touch.
• Who may connect apps, and how to see and disconnect them.
• What makes an app wait for a person, and why.
• How to change what a connected app may do, and who may.

1. What a connected app is

A person connects an app by signing in to the site from it and choosing what it may do. From then on the app works as that person: every change is recorded as theirs, “via” the app, in revisions and the audit log.

What an app may do is the smallest of three things, checked on every request:

1. The person’s roles. An app connected by an Author can never publish, because the Author can’t.
2. What the person chose when connecting it: read only, drafts only, everything they can do, or area by area.
3. What this page allows. Turn writing to navigation off here and every app loses it on its next request, without anyone reconnecting.

A developer connects Claude Code, Codex and Cursor in one step with nibble connect <site>; see The nibble command.

Removing someone’s role, or their account, ends their apps’ access at once.

2. Turning it on

Agent access is off until an administrator turns it on. Open Users → Agent access, switch on Let people connect AI apps, and save.

Below the switch is a table of every area of the site — each collection and taxonomy, globals, navigation, assets and form submissions — with a switch for Read, Write, Publish and Delete. When you first turn agent access on, apps may read content and write entry drafts, and nothing else.

Area	Write means	Why it starts off
A collection	creating entries and changing drafts	on: a draft doesn’t change the live site
A taxonomy, globals, navigation	changing them	these have no drafts, so a change is live at once
Assets	uploading and changing files	an uploaded file has a public address straight away
Form submissions	— (read only)	visitors wrote them, and they may hold personal details

Collections kept as files offer only Read: their entries live in the site’s repository.

3. Who may connect apps

A person needs the Connect apps permission. Administrators have it; give it to other roles under Roles. The Agent access page lists which roles hold it.

Signing in with a code lets an app on a server, with no browser, sign in by showing a code the person types into the Control Plane. Codes can be phished — someone sends a code and asks you to “verify” it — so the switch stays off unless someone needs it, and even then an app signed in this way can never have everything I can do.

4. Approvals

Some changes don’t wait for a person to publish them, or can’t be quietly undone: publishing, unpublishing or trashing an entry, and any change to terms, globals, navigation or assets. When a connected app asks to make one, Nibble first checks it would succeed, then holds it and notifies the person the app acts for. They see exactly what would change — with a warning if it links to another site — confirm their password, and approve or decline it. Approving makes the change there and then, once. The app has nothing more to send; it can ask how it went.

Nibble checks everything again when the change is approved, not only when it was asked for. If the app was disconnected, the person’s role or this page’s settings no longer allow it, or someone changed the same thing in the meantime, the change fails, nothing is altered, and the approval shows why. A request nobody decides on expires after a day.

Under Connected apps, a person can approve or decline several waiting requests at once, with one password confirmation.

Whether an app waits is chosen when it is connected:

• Ask before live changes, the default.
• Make changes without asking, which needs the person’s password confirmed. The app then makes these changes directly, still within its access.

On this page, Approvals decides whether people may make that choice. Each person chooses lets them; Always ask makes every app wait, whatever its person chose. An app signed in with a code always asks.

Tokens a person creates for their own scripts (under Connected apps) don’t wait: nobody is there to approve.

5. Seeing and disconnecting apps

The sidebar of the Agent access page lists every connected app on the site: whose it is, what it may do, when it was last used and from where, and when it expires. Disconnect ends it immediately.

Each person sees their own under Connected apps in their account menu, and gets a notification whenever a new app is connected to their account. An app stays connected while it is used: each use moves its expiry to 90 days ahead, and one left unused for 30 days has to sign in again. A script token ends when it was set to.

6. Changing what an app may do

An app’s access isn’t fixed when it is connected. Its name, what it may do — read only, drafts only, everything, or area by area — and whether it waits for approval can all be changed later, in two places:

• Connected apps, in a person’s account menu, for their own apps.
• Users → Agent access, for any app on the site. This needs the Manage agent access permission.

Either way, the change needs a freshly confirmed password, and the app has its new access from its next request, without signing in again. Narrowing an app also stops any change it asked for and is still waiting on: approving it later fails, because the app can no longer make it.

An administrator can widen or narrow anyone’s app, and turn its approvals on or off, but only within the same limits as the person who connected it: an app connected by an Author can’t be given publishing, whoever edits it, and nothing this page turns off can be handed to an app. An app signed in with a code still can’t have everything I can do, and still always asks. When someone other than its person changes an app, its person gets a notification saying what changed and who changed it. Every change is in the audit log.

An app that tries something it can no longer do is told what it needs — Assets: Write, say — and that its access can be changed under Connected apps.

7. What stays protected

• An app never sees a password. People sign in to the site itself, with their password, two-factor code or passkey.
• Hard deletes aren’t possible. Apps trash; a person empties the trash.
• Every change keeps its history. Revisions show who made it and through which app, so it can be undone.
• Users, roles, tokens, webhooks, redirects and settings are never available to apps.