Overview
An agent that can change your website is only useful if it respects who is allowed to change what. Give everyone unrestricted power and you have replaced a slow process with a risky one.
Role-based permissions and publish approvals mean every action is scoped to the person asking — and sensitive changes wait for sign-off. A marketing assistant can draft and edit blog posts; only the head of marketing can put one live. A contractor can touch one section and nothing else. The agent enforces this, every time, without being reminded.
The principle is deliberately simple: if a teammate could not make a change with their own login, the agent cannot make it for them either. Permissions are a ceiling, not a suggestion — and there is no phrasing, no insistence and no clever workaround that lifts them.
How it works
- You define roles — or use the defaults: Viewer, Editor, Publisher, Admin.
- Each role is scoped to content types, sections or environments as narrowly as you like.
- Approval rules route publishing decisions to the right person.
- When someone asks for more than their role allows, the work is saved as a draft instead.
- An approval request goes to a colleague who can authorise it, with the requester copied in.
What you can control
- Who can create, edit, publish or delete — each permission granted separately.
- Which content types and sections a role can reach — blog only, or everything except pricing.
- Which environments a role can write to — staging only for contractors, for instance.
- Whether code and schema changes are permitted at all, and by whom.
- Who approves what — routed by section, so the right owner sees the right request.
Why teams use it
- Custom roles — define exactly who can change what, down to the section.
- Publish approvals — route changes to the right approver automatically.
- Notifications — get pinged when something genuinely needs you, not for everything.
- Safe delegation — junior staff and contractors can work freely without risk to live pages.
Staying in control
A permission denial is a full stop, not a negotiation. The agent explains what was blocked and why, then offers the legitimate route — save as a draft and request approval from someone who can authorise it. It will not retry, switch environment or look for another way in.
Approval requests are always deliberate. You choose which colleagues are notified rather than spraying the whole team, and you are copied in automatically so you keep a record of what you asked for.
Availability
Approvals and the audit log are on every plan. Custom roles are included on Growth, Scale and Enterprise.
Frequently asked questions
Can someone talk the agent into exceeding their permissions?
No. Permissions are enforced at the connection level, not by persuasion. A denied action fails and is reported plainly — the agent does not retry, does not switch environment to dodge the block, and does not pretend the change was made.
Do roles mirror the ones in our CMS?
They work alongside them. Your CMS permissions still apply, and workspace roles add a layer on top so you can be stricter where it matters — for instance allowing someone to edit in the CMS but requiring approval for anything the agent publishes on their behalf.
How do approval requests reach people?
By email, with a review link and the requester’s note explaining why it should go live. You pick which eligible colleagues are notified, and the requester is copied in automatically so nothing disappears into a void.
Can we give a client or contractor limited access?
Yes, and this is one of the most common setups. Scope their role to a single section or to staging only, with no publish rights, and they can work productively without any possibility of changing a live page they should not touch.
What happens when someone leaves?
Revoke their access and their ability to act stops immediately, including any connected AI clients they had authorised. Everything they did stays in the audit log, attributed to them, so the history of your site remains complete.
