Know what enters.
Know where it goes.
Built-in MCIR memory gives work continuity, not broader access. Review the actual data flow: inputs, remembered context, model and tool recipients, outputs, and records left behind. The established TheoVex policies remain the source for legal scope.
An explanation,
not a replacement policy.
01two very different paths
A browser example is not a deployed API.
Sample recipe → browser simulation
- InputAuthored synthetic context and configurable sample choices. No patient records, private documents, credentials, or uploads are needed.
- ProcessingDeterministic rules run the educational example. It does not make a live model call or execute an external tool.
- OutputAn illustrative draft and trace explain the chosen path. They are not a production response or security assessment.
Browser-only describes the workbench's simulation. It is not a claim that visiting a website produces no network traffic or that the legal policies do not apply.
Your application → configured recipients → your application
- Application boundaryYour app selects the input and context, authenticates the user, and checks which resources may be used.
- Gateway and modelThe request is processed through its configured path. Prompts sent for model inference reach a model-processing recipient; do not assume they stay only in the browser.
- Tool recipientsPermitted tools receive the arguments and context needed for their action. Tool responses may re-enter the workflow. Each recipient belongs in the review.
- Response and recordsYour client displays the output. Conversations, memory, artifacts, application logs, and service records have their own handling considerations; consult the applicable documentation and agreements.
02map the minimum necessary
Review the data at each boundary.
- Input and source context
- Document the purpose of the task and the minimum data it needs. Restrict source access to the authorized owner and resource. Do not send a whole record simply because a workflow can accept text.
- Credentials and permissions
- Keep API credentials in the appropriate server-side boundary. Use the required scopes and apply end-user authorization separately. A valid API key does not by itself prove that a person may access a particular document.
- Tools and recipients
- List every system that may receive arguments, content, or generated output. Validate the action and destination, constrain permissions, and decide which side effects need review before execution.
- Logs and debugging
- Review prompts, responses, error reports, traces, and tool payloads, not only the final answer. Avoid duplicating sensitive content in diagnostics. Determine the access, deletion, and retention arrangements that apply to each record.
- Memory and persistence
- MCIR automatically recalls relevant cross-session context within an authenticated owner scope; it is not shared across tenants or used to train models. Distinguish it from one conversation, artifacts, and logs. Review retention, correction, and deletion in the current documentation and agreements, not an interface's reset button.
- Human release
- Keep review in the application where a person can inspect the evidence and recipient. A generated draft is not permission to send, publish, file, or act on its content.
03controls have a scope
A reassuring label is not a data-flow review.
Gateway Guardrails are explicitly opt-in and bound per API key. Without a binding, there is no gateway policy enforcement for that key. Bound rules evaluate their configured phases and verdicts; they do not identify every sensitive value or replace resource authorization.
Display behavior matters too. The gateway documentation describes raw tokens streaming before output evaluation, with the guarded buffer in the final event. A final correction does not mean earlier text was never exposed to the client.
The Arca report describes a separate protected serving architecture. Do not assume its scoped de-identification and routing properties apply to every model, tool, or general theo API path.
04the established documents
Read the policy at its source.
Read the established privacy document for its scope, practices, and available contact information.
Review the terms that describe the service relationship and their applicable scope.
Use the established cookie document rather than inferring site-wide behavior from a local simulation.
Review the published usage boundaries before designing or operating an integration.
questions before integration
Ask about the actual deployment.
Can I test this website with a real patient or company document?
No real records are needed. Use the synthetic examples in the public workbench and keep private documents, patient information, and credentials out of the demonstration.
Does enabling a policy mean data cannot reach a model or tool?
No. A bound policy applies particular configured rules. Review which data is sent after those rules run and which model or tool recipients are on the path. A detector is not a substitute for a data-minimization and authorization design.
Where should I check retention, deletion, or an agreement?
Start with the linked TheoVex policies and current product data-privacy documentation, then confirm the arrangements that apply to your deployment. This explanatory page does not set a new retention period or replace a contract.
Make the data-flow review concrete.
Read the current policies and bring questions about recipients, permissions, persistence, and deployment agreements to the appropriate review.