Whose permissions
"It respects the user's own permissions."
Every vendor in this category says that sentence. Whether it is true depends on two questions that are almost never asked separately, and for some systems the honest answer to both is no.
Question one: does the system accept your person's identity?
Some APIs can be called as a named person. Others accept only an application credential, in which case every request looks identical no matter who asked.
Question two: does it then enforce that person's permissions?
Accepting an identity is not the same as applying it. A system can know who is asking and still return everything.
System by system
The four rows, including the two that are ours.
| Connected system | Accepts your person's identity | Enforces that person's permissions | Whose narrowing you get |
|---|---|---|---|
| DocumentsSharePoint via Graph | yes | yes, per item | Microsoft's. The read is made with that person's own delegated sign-in, so an item they cannot open is an item they do not get. We store no credential for it and add no filter of our own. |
| TasksClickUp | no | yes, per user | The vendor's, reached with that person's own token. It is held as a pointer, revocable on its own, and usable by nobody else. |
| CRMHubSpot | no | no | Ours. The API takes an application credential only. A read returns only the records that person owns, and reading the whole pipeline is a separate tool somebody has to grant on purpose. |
| Planning modelSQL | no | no | Ours. A database connection is a database connection. The grant, the tool list, and your own row rules where you have them. |
Why publish this
Where the answer is "ours", there is nothing behind us.
Two of those four rows have no second access control. If our narrowing is wrong, nothing downstream catches it. That is worth knowing before you sign rather than during an incident.
It changes what you should test
For the Microsoft row, testing our behaviour is largely pointless: try to reach a document you have no rights to and Graph refuses you regardless of us. For the two "ours" rows, our behaviour is the whole control, so that is where your evaluation should spend its time.
It decides the design
We prefer the system's own enforcement wherever it exists, because that stores nothing and cannot drift from your access rules. Where it does not exist, the narrowing is ours and is stated as ours.
It is why the roadmap is honest
Twenty-six systems are modelled in the connection vocabulary; four have working adapters. The console says plainly which is which, rather than accepting a connection that would fail the first time somebody used it.
The comparison worth making
This is the question to put to everyone you are evaluating.
Ask any vendor
- Per system, does it accept my user's identity, or an application credential?
- Per system, is the permission check theirs or yours?
- If it is yours, what happens when your model of my ACLs drifts from the real one?
- Where is the copy, and how is it re-permissioned when I change something?
Our answers
- Two of four use your person's own identity or token.
- Two of four are enforced by us, and are labelled as ours.
- Drift cannot happen because nothing is copied; there is no second model of your permissions to go stale.
- There is no copy. Reads run against your system at the moment of asking.