Skip to main content

Credentials

OtoDock holds a lot of secrets on your behalf — AI subscriptions, API keys, and the accounts and connections behind the services your agents use. All of them stay locked down on your install and, crucially, kept out of reach of the agents themselves.

Stored encrypted​

Credentials live in OtoDock's database, encrypted with a key generated on your install. This covers:

  • AI engine connections — your Claude, ChatGPT, and API-key connections.
  • Tool credentials — the accounts users connect and the tool connections an admin sets up to reach the services agents work with (your code host, your notes, an SSH host, and so on).

Two things live outside the database by design: the platform's own signing keys are generated into your config.env (owned by the operator, never served to anyone), and the working copy of an OAuth connection's tokens sits in a server-side file that only OtoDock itself can read. Either way, they stay on your server, out of everyone else's view.

One file to guard: the key that encrypts all of this is generated into your .env (config.env) on first run. Back it up alongside your database — a restore without it can't decrypt your stored connections (see Upgrading & Backups).

How tools get their credentials​

Tools (MCPs) authenticate in a few clearly-separated ways:

  • Personal accounts — each user connects their own account for an integration (your own code host or notes workspace, for example). It belongs to you, and an agent uses it only when you're the one driving.
  • Admin-configured tool connections — for shared infrastructure tools (an SSH host, or a service on your own network), an admin sets up the connection once — its address and any token or key — in MCP Servers. Every agent that uses the tool shares that one connection.
  • Agent service accounts — for work that runs on behalf of an agent rather than a person (agent-scoped tasks and chats — like a support agent handling incoming triggers), a manager designates one of their own connected accounts as the agent's identity, per supported tool, on the agent's Settings → MCPs page.

There's no platform-wide pool of shared personal logins: an agent acts as someone's account only when a manager has deliberately bound one of their own to it.

Secrets stay out of the agent's reach​

A capable agent can read files and run commands, so OtoDock takes care that its secrets never sit somewhere it could browse:

  • Credentials are delivered to each tool privately, scoped to that one tool and that one session — not written into shared configuration files.
  • OtoDock's configuration and credential stores are blocked from agent tools — in every mode, for every role — so an agent can't read them to lift a token out.
  • When an agent connects to a service over the web, the access token is attached to the request behind the scenes — it never lands in the agent's view.

A session does carry the credentials for its own work — the engine token it runs on and, for a few tools, an account deliberately made available to it (connecting GitHub, for example, is what lets git just work in chat). The boundary OtoDock holds is that a session only ever holds what it's already authorized to use — never another user's credentials, and never the platform's.

Connecting and disconnecting​

You manage connections from the dashboard:

  • AI engines under User Settings → AI Engines (and Setup → AI Engines for admins). See Connecting your AI.
  • Service integrations under User Settings → Integrations, with a guided sign-in for each provider. See Integrations.

Disconnecting cleanly removes the stored credential and tidies up anything that depended on it.

OAuth, handled for you​

For services that use OAuth sign-in (GitHub and Notion), OtoDock runs the standard consent flow, keeps the resulting tokens on your server where only it can read them, and keeps them refreshed automatically so connections don't silently expire. You sign in once and the agent stays connected.

Next steps​