MENSARA.AI · A GOVERNED MIND, IN YOUR ACCOUNT
Sign in
Mensara Create account

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)