Whose permissions
"It respects the user's own permissions." Asked of four systems, answered honestly for each.
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.
Every vendor says the user's own permissions are respected. This page says, per system, who is enforcing them.
Question one: does the system accept your person's identity?
Some APIs can be called as a named person, which is delegated access. 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.
| System | Accepts your person | Enforces their permissions | Whose narrowing |
|---|---|---|---|
| Documents, via SharePoint | yes | yes, per item | Microsoft's |
| Tasks, via ClickUp | no | yes, per user | the vendor's |
| CRM, via HubSpot | no | no | ours |
| Planning model, over SQL | no | no | ours |
| Connected system | Whose narrowing you get, and what that means |
|---|---|
| DocumentsSharePoint via Graph | 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 | 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 | 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 | Ours. A database connection is a database connection. The grant, the tool list, and your own row rules where you have them. |
Two of those four rows have no second access control.
If our narrowing is wrong on the Microsoft row, Graph refuses the read anyway and nobody is harmed. If it is wrong on the other two, nothing downstream catches it. That asymmetry is the single most useful thing on this page.
The weak rows, in detail
What "ours" actually consists of.
Saying the narrowing is ours is only useful if you can then examine it. So here is what it is made of on those two rows, what compensates for the missing second control, and what to do if that is not enough for your review.
| On a row where the narrowing is ours | What it is made of |
|---|---|
| The tool, before the databoth systems | The person holds a tool or they do not, and a tool they do not hold is not offered and is refused if called anyway. The tool that reads one record and the tool that reads the whole pipeline are different tools, granted separately, so "read the CRM" is not one permission. |
| Ownership, inside the readCRM | A read returns only the records that person owns in the source system. That is a filter we apply from a field the source system maintains, so it is only as good as your own hygiene there. If your ownership fields are stale, so is this. |
| Row rules, where you have themplanning model | Your own restrictions on which slices a person may read, expressed against the model rather than inferred. Where you have not written any, there are none, and a person holding the read tool can read the model. That is the sharpest sentence on this page, and it is here rather than in a footnote. |
| The environmentboth systems | A grant names one environment. Holding a tool on test grants nothing on production, and there is no request shape that reaches both. |
What compensates for the missing second control
- Every call is recorded either way, with the person, the environment, the tool and the reason. On these two rows that record is not a nice-to-have, it is the detection you would otherwise get from the source system refusing something. See the audit trail.
- Nothing is copied, so a mistake here is one wrong answer to one person at one moment, rather than a wrong copy that keeps answering.
- Revocation is immediate. Removing the grant takes effect on that person's next question, with no cache and no standing access to withdraw separately.
What to do if that is not enough
- Grant the narrow tool only. On the CRM, the ownership-filtered read is one tool and the whole-pipeline read is another. Most people need the first.
- Write the row rules. On the planning model this is the control, and it is the one thing on this page that is yours to configure rather than ours to promise.
- Or do not connect it. A client who connects nothing is still a served client: the handbook tools and the project list need no connected system at all.
Why publish this
Where the answer is "ours", there is nothing behind us.
That is worth knowing before you sign rather than during an incident, and it changes what your evaluation should actually spend its time on.
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 console will not lie to your admin
Every system in the connection vocabulary carries its category and its sign-in mode, and the console states which narrowing applies before a connection is saved, rather than accepting one 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.