One page for the organization’s data posture: where data may go, and who may send it. Residency states where data is stored or processed under the service design; it is not the same as sovereignty or a promise that no external provider receives data.
Residency
Where covered data is placed.
- Configured region
- Storage and processing design
- Organization setting
Sovereignty
Who owns and governs the provider.
- Provider ownership
- Legal jurisdiction
- Support and control model
Read the provider path
Tindre’s core services and configured model or Connector providers can receive different data for different purposes. Review the current subprocessor and provider information before a regulated rollout.
Understand optional providers
Some external services only become involved when an administrator enables the related feature. Turning one on changes the data path and should follow the organization’s approval process.
Control API and MCP access
The page includes organization-wide policy caps for API and MCP access. The caps reach personal access tokens and external clients, not the dashboard: the door can be closed outright, or capped to reads, which blocks every change including an administrator's.
Decide what members may bring
Two settings say whether a member may connect their own account to an approved integration, and whether they may point their own tools at an MCP server they run. A personal connection appears only in that person’s own tools, never on a customer-facing surface.
An agreement can freeze the page
When the security posture is fixed by the organization’s agreement with Tindre, everything here becomes read-only and the page says so.
Residency is not sovereignty
A regional storage location does not by itself answer ownership, legal jurisdiction, support access, model processing, or subprocessor questions. Evaluate those dimensions separately.