How Narrow Should an AI Agent's Credential Be?

How narrow should an AI agent's credential be?

As narrow as the job it is doing this week, and no wider. If an agent drafts CMS items, it needs the CMS scope and nothing else. Every additional permission you attach is a capability you are trusting a probabilistic system not to use by accident.

This sounds obvious and almost nobody does it. The common pattern is one token with everything switched on, created once in a hurry, then reused for every automation because it already works. That token becomes the most dangerous object in the business, and it usually has no owner.

So let me be concrete rather than preachy, using Webflow's own permission model, because it is unusually granular and it makes the argument better than an abstract lecture about least privilege.

What does a scope actually control?

Access to one resource, in one direction. Webflow's documentation defines scopes as permissions that control what data your app can access, and notes that they usually come in pairs, with read for viewing data and write for modifying it.

The reading and writing split is the first and cheapest decision you can make. An agent that audits your site, reports on it, or drafts suggestions does not need write access to anything. That is not a small distinction. It is the difference between an automation that can be wrong and an automation that can be wrong and destructive.

Webflow's own guidance says the quiet part clearly. Its scopes page advises requesting only the scopes your app actually needs, and notes that requesting unnecessary ones can make users hesitant to approve your app. That framing is about trust between developers and users, and the same logic applies to trust between you and your own automation.

Where the scopes live matters too. Webflow separates site-level scopes from workspace-level scopes depending on the type of token you create, and it notes that each API endpoint lists its required scopes in its description. So the correct scope list is discoverable rather than guessed, which removes the usual excuse for granting everything.

What does genuinely granular look like?

Look at how Webflow scopes page branches. Its documentation lists six separate scopes for that one resource: read, create, delete, update, merge, and publish. Six switches, for one feature.

Sit with what that enables. You can give an agent permission to read branches and create them, while withholding merge, publish, and delete. That agent can prepare work and can never put it live or destroy it. A human reviews and merges. The agent does the tedious part and cannot reach the irreversible part.

That is the shape I want every automation to have, and it is worth naming as a principle rather than a Webflow detail. Split permissions by reversibility, not by resource. Reading is free, writing is recoverable, publishing is public, and deleting is permanent. Those four deserve four different levels of trust, and a permission model that lets you separate them is doing you a favour.

Most tools are less granular than this, and that is a real constraint rather than an excuse. When a platform only offers read and write, the compensating control has to live in your workflow: the agent writes drafts, and a separate step that the agent cannot trigger promotes them. I have written about the general version of this in having agents work in CMS drafts.

Why is read versus write the wrong place to stop?

Because write covers two very different risks that people treat as one. Changing a field and removing a record are both writes. The first is annoying to undo. The second may not be undoable at all, and a permission model that cannot tell them apart forces you to trust an agent with both.

Webflow's branch scopes show the fix, but the reasoning generalises. Before granting a write permission, ask what the worst single call with that permission would do. If the answer is that a page comes back wrong and you republish it, that is a tolerable write. If the answer is that something is gone, that permission belongs to a human.

There is a second reason to look past the read and write pairing, and it is about scale rather than severity. An agent with write access to one collection can damage one collection. An agent with write access at workspace level can damage everything, and the difference between those two is a dropdown you clicked once.

Webflow makes one of these boundaries explicit in a way I find genuinely useful. Its documentation notes that the custom code scopes are available only to data client apps, and that site tokens cannot access custom code endpoints at all. Some capabilities are simply off the table for a given credential type, which is a stronger protection than remembering not to use them.

What should you never hand an agent?

Anything that creates more permissions. That is the one category I hold absolutely, because a credential that can mint credentials converts every other limit you set into a suggestion.

Webflow puts a human in that loop by design. Its documentation says only site administrators are authorised to create a site token, and that if you are not an administrator you need to ask one. The token itself, in Webflow's words, acts as a unique identifier and password, and it verifies what the holder is allowed to do through scopes and permissions.

The second thing I would withhold is user management. An automation that can add, change, or remove users is an automation that can change who else has access, and that is the same failure with a different label. If your workflow genuinely needs it, that workflow needs a human approval step, not a wider token.

The third is billing and plan changes, for the boring reason that they cost money and are awkward to reverse. None of this is because agents are malicious. It is because the consequences of a confident mistake in these three areas are qualitatively different from the consequences everywhere else.

How do you know what an agent actually did?

You need an activity trail, and you need to have granted the permission to read it before you need it. Webflow exposes this as its own scope, with a site activity read scope at site level and a workspace activity read scope at workspace level for workspace audit logs.

Notice that reading the log is a separate permission from doing the work. That separation is correct and worth copying. The credential your agent runs on and the credential you use to review what it did should not be the same credential, because an agent that can read its own audit trail can, in principle, be asked to summarise it selectively.

Webflow's MCP documentation adds the other half of the picture, stating that every agent works within your existing Webflow permissions and roles, and that each site can provide its own Agent Instructions to guide how agents work on it. So the boundary an agent operates inside is the boundary you already configured for people, which means your access review is now also your agent review.

The practical habit I would build is small. Once a week, read the activity for anything an automation touched, with your own credential, for five minutes. Not because you expect to find something, but because the first time you look should not be the day something went wrong.

What breaks when you scope too tightly?

Things fail in confusing ways, and you should expect that rather than be surprised by it. A missing scope usually produces an authorisation error at the moment of the call, which means an automation can run correctly for weeks and then fail the first time it reaches an endpoint you did not anticipate.

That failure mode is annoying and it is still the right trade. A loud failure you can fix is better than a silent capability you did not intend to grant. What makes it manageable is Webflow's note that each endpoint lists its required scopes in its documentation, so mapping a workflow to its scope list is a reading exercise rather than a guessing game.

My practical method is to start with read-only, run the automation in whatever dry-run form the tool allows, collect the authorisation failures, and add exactly the scopes those failures name. That produces a minimal list derived from behaviour rather than from imagination, and it takes an extra twenty minutes once.

Write the resulting scope list down next to the automation, with the date and the reason for each scope. Six months later, when someone asks whether this token still needs write access to forms, the answer should be in a file rather than in somebody's memory. That is the same discipline as an automation runbook written before you ship.

How do you decide the scope before you build?

Write the sentence describing what the automation does, then underline every noun and every verb. The nouns are your resources. The verbs tell you whether you need read, write, or something more dangerous. That is the whole exercise and it takes two minutes.

Draft blog posts from a research pipeline becomes CMS, read and write, and nothing else. Report on which pages lost traffic becomes read on analytics and read on pages, with no write at all. Publish approved items on a schedule is the one where you should pause, because publishing is the irreversible-in-public verb and it deserves a deliberate decision rather than an inherited token.

Then do the part people skip: decide what happens when the automation's job changes. Most over-permissioned tokens did not start that way. They accumulated, one urgent Friday at a time, and nobody went back. Put a date in your calendar to re-read the scope list, or accept that it will only ever grow.

One credential per automation is the other rule I would hold. It costs a few minutes to create and it means that revoking one workflow does not break four others, which is the situation that makes people leave a compromised token in place because they are afraid of what else it is holding up.

Does this change if the agent is only reading?

It gets easier but it does not disappear, because read access is still access to information. An agent with read access to forms can read form submissions, which on most business sites means names, email addresses, and whatever else people typed into a contact box.

So I would still separate read scopes by sensitivity rather than treating all reading as harmless. Reading your CMS content is reading things you already published. Reading form submissions, users, or ecommerce data is reading things people gave you privately, and those deserve a narrower credential and a clearer reason.

The test I apply is whether the data would embarrass you if it appeared somewhere unexpected. Published blog content fails that test in the reassuring direction. A list of customer email addresses does not, and it should not be attached to a token that exists to draft articles.

What should you do next?

Go and look at the token your automations are using right now. Not the documentation, the actual token and its scope list. If you cannot find where it is defined, or you find one token doing five jobs, that is the finding and it is worth an hour today.

Then rebuild one automation on a purpose-made credential with the minimum scopes it needs, derived from the errors rather than from guesswork, and write the list down beside it. Do the highest-risk workflow first, meaning whichever one can publish, delete, or touch customer data. The rest can wait for the pattern to prove itself, and letting an agent publish directly to your CMS is the decision I would examine hardest.

If you want a second pair of eyes on how your automations are authenticated before you widen anything, reach out. It is usually a one-hour review and it tends to end with fewer permissions rather than more.