
203 Permissions For Us, 127 For The Client. The Dangerous One Is In Both.
203 permissions for us. 127 for the client. The dangerous one is in both.
Systems Ninjas (2026). What an agency login can actually read on a leading marketing platform. Permission model measured 2026-08-14 against the live IAM enumeration: 203 agency-administrator scopes against 127 default account-user scopes. systemsninjas.com/post/agency-crm-access-what-can-they-see
Take any of it. You do not need to ask. If you find an error in here we would rather hear about it than not, and the correction goes on the page.
More than the menu suggests. The default settings are the problem.
A login is a key card. What matters is not the job title printed on the front. What matters is which doors it opens.
On the platform most marketing agencies build on, the standard client key card opens a store room most people do not know is there. Inside are shared links, connection settings, and, if nobody has tidied up, API keys. An API key is the password one piece of software uses to talk to another. Hiding every automation menu from the client does not lock that door.
We counted what that key card opens instead of trusting the manual. Here is what is in there. At the end there are three questions worth asking any agency, including us.
01 / The modelWhat we counted
Every user carries a plain list of permissions. One line for each thing they are allowed to do. The platform calls each line a SCOPE.
There is no tidy set of job roles and no dial you can turn up or down. It is a list, with the person's type (agency or account) and role (admin or user) written beside it.
We counted them on a live account on 2026-08-14:
- 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 standard client login is not safe
The standard client list includes one called settings-write. That one opens Custom Values.
Custom Values is the cupboard where a system keeps anything that has to read the same everywhere at once.
A well built system keeps shared links, opening hours, prices and intake dates in there. On a system nobody has checked, it is also where API keys end up.
So the picture most people carry is wrong. Hiding the Automations menu and the AI tools does stop a client reading what the bot was told to say. It does not stop them reading the values the bot pulls in while it says it.
Two consequences.
If you are buying automation: "you can log in and see everything except the automations" tells you nothing useful. It describes a menu. It does not describe a key card.
Ask what your login can READ, not what it can EDIT. Ask about the shared-values cupboard by name.
If you are the one building: a permission being missing from the standard list is not the same as it being locked away. Anyone who can manage the team can hand any permission to anyone, at any moment.
The standard list is a starting point, not a wall. A written policy is a promise, and a promise stops nobody on its own. Something has to check.
03 / Two questions closedTwo questions we could not answer before, and now can
Can connection tokens be locked down on their own? Yes. A token is a password a program uses in place of a person logging in.
Four separate permissions cover them: read and write, at the single-account level and at the whole-agency level. None of the four is in the standard client list.
That closes a real hole. A token made this way walks straight past every restriction in the menus, the way a spare key gets past a locked front door. Hiding the menu AND holding back those four permissions is a full answer. Hiding the menu on its own is not.
Can you give someone the bot's knowledge without giving them the bot? No. There is no permission for it at all. Nothing with the word "knowledge" in it appears anywhere in the 203 permissions.
That is not a small detail. If a client is going to edit what their bot knows, the knowledge has to live somewhere else and be fed in.
We keep it in a shared document the client owns and edits, and the platform reads from it. We already liked working that way. After counting, we know it is the only way that works.
04 / Two things that existTwo things that already exist
There is an audit log. Permissions to read it and to export it both exist at agency level.
So the "we lost a morning working out who changed what" problem already has a tool, at least in part. Use it. Do not rebuild the story from memory.
You can save a set of permissions and reuse it. Build the role once, then apply it to each client, instead of ticking boxes by hand for every new login. If your agency sets up each login by hand, expect them to drift apart over time. Hand-made copies always do.
05 / LeavingWhat happens when you leave
This is the question everyone forgets to ask until it matters.
Separate accounts really are separate. Contacts do not flow between them. The platform's own copy tool runs one way only, and it leaves behind conversations, notes, appointments and payment history.
So "we will just move your data across" is a sentence to ask hard questions about before you lean on it.
Ask for the export before you need it. Contacts and their extra fields come out cleanly. Conversation history, the logic inside your automations and the bot setup do not.
Being able to export your contact list is not the same as being able to pick up your whole system and carry it out of the door.
06 / The frameHow we explain it, and why it binds us too
We do not hand clients edit rights on their live system by default. The reason is not "we are protecting our work from you". That would be a poor reason, and it would not be true either.
The reason is:
Nobody edits the live system directly. Not you, not us. Everything is built and tested somewhere else first, then moved across. You get your own account on exactly the same terms: load anything, build anything, break anything.
That is how every serious software team works. The rule sits on us as heavily as it sits on you, and that is the whole point of it.
Tell a client this at the start and it is fine. Let a client DISCOVER a locked door six months in and they feel distrusted. They are right to.
If you want to build your own automations, you get somewhere to build them. What you do not get is the power to change the live system that is taking your bookings today. Neither do we, without going through the same door.
07 / Ask theseThe three questions to ask any agency
- What can my login READ? Not edit. Read. Ask about shared values and connection settings by name.
- Can you show me the export? Not describe it. Run it, and show what comes out and what does not.
- Who else has a login on my account, and can you list them today?
If the answers are vague, that is your answer. Ask us the same three and we will send you the list.
We counted the permissions on the live platform on 2026-08-14. The names and the counts are the vendor's, not ours, and they change. Check again before you rely on the numbers.
Ask us the three questions and we will answer them in writing
Send them to us about your own current setup, or about ours if you are thinking of working with us. We will tell you what your login can read, run the export in front of you rather than describing it, and list every person who holds a login. If the answer is unflattering you will get that version.
Ask the three questions [email protected] · No client of ours is named anywhere on this page, and if you become one, you will not be either.