203 permissions for us. 127 for the client. The dangerous one is in both.

More than the menu suggests, and the default settings are the problem. On the platform most marketing agencies build on, the out-of-the-box client login can read the place where shared links, integration settings and (if nobody has cleaned up) API keys are stored... even after every automation menu has been hidden from them.

We measured the permission model rather than reading the documentation. Here is what is actually in there, and the three questions worth asking any agency, including us.

01 / The modelThe model, as measured

The platform uses a flat list of permission SCOPES per user. Not a tidy set of nested roles, not a slider: a list, one entry per capability, with the user's type (agency or account) and role (admin or user) alongside it.

We counted them on a live account:

• 203 scopes on an agency administrator
• 127 scopes on a default account user, which is what a client login normally is

That gap is where the whole question lives.

02 / The findingThe finding that matters: the default client login is not safe

The default account-user set includes the settings-write scope. That scope reaches Custom Values, which is the platform's shared-variable store.

Custom Values is where a well-built system keeps things like shared links, opening hours, prices, intake dates ... anything that must stay identical everywhere. It is also, on a system nobody has audited, where API keys end up.

So the picture people assume is wrong. Hiding the Automations menu and the AI modules does stop a client reading the bot prompts. It does not stop them reading the values those prompts draw from.

Two consequences.

For a business buying automation: "you can log in and see everything except the automations" is not a specification. Ask what the login can READ, not what it can EDIT, and ask specifically about the shared-values store.

For anyone building: the absence of a scope from the default set is not protection. Any user holding team-management-write can add any scope to any user at any time. The default is a starting position. The written policy is the only thing that is actually an assertion, and it protects nothing unless a tool enforces it.

03 / Two questions closedTwo questions we had open, now closed

Can integration tokens be locked down independently? Yes. Four discrete scopes govern private integrations (read and write, at location and company level), and all four are absent from the default set. This closes a real hole, because a token minted through that surface bypasses the interface restrictions entirely. Hiding the menu AND withholding those four scopes is a complete answer. Hiding the menu alone is not.

Can a knowledge base be granted separately from the AI that reads it? No, because there is no knowledge-base scope at all. Nothing matching "knowledge" appears anywhere in the 203-scope enumeration.

That is not a small detail. It means the only way to give a client editable control of what their bot knows, without giving them the bot, is to put the knowledge somewhere else entirely and sync it in. We use a shared document the client owns and edits, which the platform reads. That was already our preference. After this measurement it is the only design available.

04 / Two things that existTwo things worth knowing exist

There is an audit log. Read and export scopes for it exist at agency level. The "we spent hours working out who changed what" problem has a partial tool already, and it is worth wiring into your change process rather than reconstructing history from memory.

Permission templates exist. A role can be defined once at agency level and applied per client, instead of ticking boxes by hand for every new login. If your agency is hand-configuring each one, they are doing it the way that drifts.

05 / LeavingWhat happens when you leave

This is the question everyone forgets to ask until it matters.

Separate accounts are genuinely separate. Contacts do not sync between them. The platform's own copy-contact tool is one-way, and it drops conversations, notes, appointments and payment history on the way through. So "we will just move your data across" is a sentence that needs unpacking before you rely on it.

Ask for the export before you need it. Contacts and their custom fields export cleanly. Conversation history, workflow logic and bot configuration do not travel the same way. A business that can export its contact list is not the same as a business that can lift and shift its system.

06 / The frameThe frame we use, and it cuts both ways

We do not give clients edit rights on their live production system by default. The reason we give is not "we are protecting our intellectual property from you", because that is a bad reason and it is also not quite true.

The reason is:

That is how every serious software team works, it is reciprocal rather than hierarchical, and we hold ourselves to it. A client told this at the start is fine. A client who DISCOVERS a locked door six months in feels distrusted, and they are right to.

If you want to build your own automations, you get a place to build them. What you do not get is write access to the live system that is currently taking your bookings, and neither do we without going through the same door.

07 / Ask theseThe three questions to ask any agency

1. What can my login READ? Not edit. Read. Ask specifically about shared values and integration settings.
2. Can you show me the export? Not describe it. Run it, and show what comes out and what does not.
3. Who else has a login on my account, and can you list them today?

If the answers are vague, that is the answer. Ask us the same three, and we will send you the scope list.