MENSARA.AI · A GOVERNED MIND, IN YOUR ACCOUNT

Set safe boundaries · GUIDE 10

Decide where your information may go

Before you use Mensara for work that matters, decide where your notes may be stored, which connected AI or service providers may receive them, and who operates the systems involved. The answer depends on the configuration you choose.

Ask about the paths that matter

When you share notes with a connected assistant, that assistant can process the material it is allowed to read. If the material is included in a request to an AI provider, that provider can receive it. A backup service is another possible destination for your information and its history.

The account service may also hold account and billing details and basic service-health information. The documented design says this service should not store or pass along the content of your notes, documents, prompts, or sensitive credentials. That is a stated design boundary. It is not proof of the retention, logging, support, backup, export, or deletion practices in every configuration.

Make the decision for your setup

Ask for the terms that apply to the AI providers, backup service, and hosting arrangement you select. Ask what information can leave your environment, who can operate the storage, what backups retain, and what remains after deletion. A vendor-operated cloud account and a customer-operated or on-premises arrangement can involve different access to the underlying systems.

Do not rely on a general claim that information “stays local.” Review each path that matters to your organization.

Related

Who can read and suggest changes?

NEXT GUIDE · 11 Suggest a correction and check its result An assistant can help spot a correction without being able to change the source itself. A suggestion is not the same as a saved change. →

MENSARA.AI · DECIDE WHERE YOUR INFORMATION MAY GO · AGENT VIEW · TEXT/MARKDOWN

# Trust-boundary procedure

Use this source-based model when evaluating a particular deployment; do not represent it as a completed custody audit. The host application boundary permits account, organization, membership, billing/entitlement, box identity/enrollment, version, and coarse health metadata. Its policy prohibits storing, proxying, or logging brain content, prompts, chat history, documents, detailed receipts, provider keys, and credentials entering a box.

That application boundary does not make a vendor-hosted VM inaccessible to the cloud-account owner. Customer-owned cloud accounts or on-premises infrastructure are documented as the stronger separation option.

For an authorized model use, the portal constructs its client toward an on-box egress broker with the acting user's consumer token and route; the inspected chat client does not decrypt provider credentials. The upstream serializes a request and POSTs it to the configured endpoint, adding a bearer key when supplied. Therefore, content included in the model request can leave the box for the selected provider. Content returned over an authorized MCP connection can also be processed by the external agent.

For backup, the contract describes pushing whole repository Git history, including audit history, to a configured remote. Do not infer an export schema, restore success, provider retention/training terms, credential location, a deletion guarantee, or coverage of every service from this evidence. Obtain the deployment-specific terms before treating any of those as true.

There is no runnable trust probe or idempotency/retry rule supplied. Report missing deployment details as unresolved rather than filling them with architecture assumptions.

## Continue

[Read and proposal permissions](/how-it-works/read-and-propose)

[Generated tool input reference](/how-it-works/tool-inputs.md)