Security model
How access is decided, and what enforces it.
Two independent questions
LensHub separates what you can do from what you can see.
Role decides actions — inviting people, creating connectors, changing settings.
Ownership decides visibility — whether a piece of content appears in your results at all.
They do not imply each other. An administrator can manage the whole instance and still not read another person's private content. This is deliberate: operating the system should not require the ability to read everything in it.
Where visibility is enforced
Inside the database queries themselves, not in the interface and not at the route. Every read carries the identity of the person asking, and content that is not theirs to see is filtered before results are assembled.
The consequence: there is no path — REST, agent, or otherwise — that returns content the requester is not entitled to. It is one mechanism rather than a check repeated per feature.
A regression test suite exercises this across users and organizations on every change.
Agents inherit their creator's access
An API key can never do more than the person who created it can do today. Roles are checked live, not captured when the key was made. Demote someone and every key they hold drops with them.
So an agent is exactly as trusted as its owner. No more.
Organizations do not leak
Every query is scoped to one organization. Nothing crosses.
What is recorded
Administrative actions and authentication events, including failures, with the source address. See Audit logs.
Reasonable expectations
LensHub protects content from people who should not see it, and records who did what. It does not protect against someone who already holds valid credentials for content they are entitled to see — which is why key hygiene and offboarding matter.