Safety and control

Keep your files and credentials under control

Otto keeps your files on your Otto and never hands an agent or a model your app passwords. This page explains where each kind of credential is held, what may be sent to a model or external service, and the checks to make before you let work run unattended.

The short version

Your files and browser sessions live on your Otto, not in Otto's cloud services. So do the credentials you add yourself for a custom API or MCP server: they never leave the device.
For most apps you connect from Otto's catalog, the authorization is held by Otto's cloud connection service, which carries out the app actions your Otto requests. It is not stored on the device.
A connection authorizes Otto to use an app. It does not give an agent or model your raw app password or the app's access token.
A connected app is connected to the Otto, not to one agent. Every agent on that Otto can use it. There is no per-agent list of connections.
Information needed to complete a request may be sent to the cloud model or external service that handles that request. Share only what the job needs.

What lives on your Otto

Your Otto is the computer where your agents, files, and browser sessions are kept, along with any credential you add yourself for a custom API or MCP server. Otto's encrypted relay lets you reach the device remotely without opening inbound ports or configuring a VPN.

This does not mean every piece of information stays on the device during a task. For example, an agent may need to send relevant instructions, file content, or connected-app results to a cloud model so the model can reason about the work. An external service may also receive the data required for an action you asked Otto to perform.

How app connections protect credentials

When you connect an app from Otto's catalog, you complete the provider's own authorization flow. For most catalog apps the resulting authorization is held by Otto's cloud connection service, scoped to your Otto, and app actions your Otto requests are carried out through that service. A credential you add yourself for a custom API or MCP server is different: it is stored on the device and never sent to Otto's cloud. See Add a custom API or MCP server.

In both cases the agent works through Otto and never sees the token; it should not need you to paste a password, access token, or recovery code into chat.

A connection and an approval are different controls:

Connection: which account your Otto can reach. Every agent on that Otto can use a connected app; a connection cannot be limited to one agent.
Automation access: one level per automation — none, read-only, or read and write — that applies to every connected app at once. It does not select individual apps.
Approvals & safety: when Otto asks before an action with an external consequence, such as sending, publishing, purchasing, deleting, or changing a record.

Disconnect an app when you need to remove Otto's access. Changing an approval setting does not revoke the connection. See Manage connected app access for review, reconnect, and disconnect steps.

Before asking an agent to use a file, conversation, browser session, or app, consider:

Purpose: what exact result does the agent need?
Scope: which files and accounts are necessary? Remove unrelated material from the task, and remember that a connected account is available to every agent on that Otto.
Destination: could relevant content be sent to a cloud model or an external service as part of the work?
Consequence: could the agent send, publish, purchase, delete, or change something? Set the approval behavior before you start.

Do not paste passwords, recovery codes, or other credentials into a chat. Use the provider's connection flow instead. Treat files and browser sessions as sensitive context even when they do not contain a password.

A safer setup for unattended work

Connect only the account the workflow needs from Settings > Integrations.
Give the task or agent only the files and instructions it needs, and keep only the apps you actually use connected.
Start with a small, read-only task and review the result.
Keep Approvals & safety set to ask before consequential actions until you understand the workflow. See Approvals and safety controls.
Review the automation's permissions and limits before enabling a recurring schedule.
Disconnect an app when the project ends, the account changes hands, or the agent no longer needs it.

Separate agents keep instructions and conversation context apart, but they share the Otto's connected apps. If one role must not be able to reach an account at all, do not connect that account to this Otto; use a separate Otto for a hard boundary.

Before transferring or retiring an Otto

If someone else will use the device, remove it from your account and wipe or unpair it through the app before handing it over. This is the step that removes your personal files, credentials, agent state, and access from the device for the next owner. Do not rely on changing an agent's instructions or disconnecting one app if the device itself is changing ownership.

If you are only retiring an app connection, use Settings > Integrations and choose Disconnect on that app. Existing conversation history, instructions, and files are not automatically removed when an app is disconnected; remove sensitive context separately when it is no longer appropriate.

If you are unsure what an agent can access

Check the agent's instructions and the files you have given it.
Review the Otto's connected apps in Settings > Integrations. Every agent on the device can use every app listed there.
Review the automation's permissions, limits, and approval behavior before enabling unattended work.
Inspect a run in Automations > History to see what happened; the run log does not grant new app access or bypass an approval.
If access is broader than intended, stop the work, disconnect the unneeded app (this removes it for every agent), remove the unnecessary context, and then retry with a small test.