Access control

A key sees exactly what its user can see in the Sentinel app, checked on every call.

Every request runs as one Sentinel user. Before returning a matter, a document or a search hit, Sentinel checks that user's access with the same rules the Sentinel app uses.

#Matters

GET /matters lists only matters the caller can access. Any endpoint that names a matter or document the caller can't see answers 404, never 403, so a key can't probe which IDs exist.

Removing someone from a matter takes effect on their next request.

#Documents

The REST API covers a matter's Discovery documents. A document appears only when all of these hold:

• The caller can access the matter.
• The caller is on the matter's Discovery room. If a room's access list leaves someone off, its documents don't exist for them.
• The document isn't fenced from the caller. Users whose access to a matter is limited never see documents marked attorneys'-eyes-only, in lists, search results or reads.

Sentinel decides these on the server for every request. A caller can't ask to skip them.

#Search

Search runs with the caller's restrictions, and every hit is checked again against the same document rules before it's returned. A search can't surface a document the list wouldn't.

#Keys keep their role

An API key, including one created by an OAuth sign-in, keeps the role its user had when it was created. If a user's role is reduced, revoke their keys so the change also applies to their integrations. Admins can do that from Firm → Connected apps & API keys.

#MCP server

The MCP server checks matter access on every tool call, and refuses every request from an account with limited access to any matter. See MCP server.