Connections
Let people reach your agents, and let your agents use the services you choose
Connections
The Connections page brings the outside world into one place. It has two regions:
- Messaging lets people reach your agents through services such as Slack and Telegram. See Relay Messaging.
- Accounts lets agents use services such as Gmail. You choose an account, a named agent, and the exact actions or notifications it may use.
This guide covers Accounts.
DorkOS-managed Accounts are available in alpha. A real Gmail sign-in, profile read, usage record, and access removal have been verified. This does not certify every service. Managed account notifications remain unavailable while their separate live delivery check is incomplete.
Connect an account in three steps
Choose a service
Open Connections and find Accounts. If you see Link DorkOS account, select it to open Settings → Access. Choose Link this instance and finish signing in to your DorkOS account. Return to Connections → Accounts and select Connect service. Search for a service, then choose its account button, such as Use a Gmail account.
Supported services use Composio-managed sign-in by default, without a separate developer setup. An explicit custom setup takes priority when one exists. Services that need unsupported or custom setup stay visible and explain what is missing. When more than one route is ready, you can change the route before continuing.
Sign in
Read where the service will keep your login access. Add a label such as “work” if you plan to connect the service more than once. Open the sign-in page and finish the service's flow. Managed OAuth consent may name Composio because Composio holds the connection in its vault. Some services instead ask for account fields on dorkos.ai. Our servers pass these details to Composio without saving them, and they never pass through your local installation or an agent. A service that needs no account fields still asks you to confirm. You can close the DorkOS dialog while an external sign-in flow continues.
Choose agent access
Open the new connection and choose Agent access. Pick a named agent, then review the exact actions it may use. OAuth scopes decide which service actions are available; your agent grant decides which of those actions this agent may run. Notification access is a separate choice. New or changed actions stay off until you review them.
You can connect several accounts for one service. Labels keep a personal account separate from a work account. Access always belongs to the exact connection you selected.
Agents can ask, but you decide
An agent can ask for a service and explain why it needs access. The request does not reveal your private account list and does not grant anything. DorkOS opens an owner review where you choose the connection, actions, notifications, and destination.
If the request is still attached to a live turn, the agent receives the result there. After a restart, DorkOS can continue the exact recorded session once. A denied, expired, failed, or deleted request grants no access.
Actions and notifications are separate
DorkOS-managed account notifications are not available yet. The choices below describe notification access when the selected route supports it. Slack and Telegram Messaging are separate from this limitation.
An action grant lets an agent run a reviewed operation, such as reading a profile. It does not let the agent receive account activity.
A notification grant names all of these:
- the exact connection;
- the activity type and any supported filter;
- the receiving agent;
- the destination, such as an agent session, room, or supported messaging destination.
To change a notification's scope, remove it and create a reviewed replacement. Standalone notification editing and pause controls are not part of this release. Pausing the whole connection remains available.
Delivery timing comes from the service. Some services send webhooks, some check on a schedule, and some do not report their timing. DorkOS does not label every notification as real time.
Choose where account access runs
| Route | Who supplies the service project | Who holds the service login | Hosted offline notification buffer |
|---|---|---|---|
| DorkOS-managed | DorkOS | Composio's vault | Yes, after that capability passes its separate readiness gate |
| Your Composio project | You | Composio's vault | No. Your installation receives events directly. |
| Nango on your server | You | Your Nango database | No |
| Raw MCP server | You configure the server | The remote server | No |
DorkOS does not charge for account actions in this release. Usage records distinguish which party's service project handled an attempt, but there is no billing or invoice flow.
Composio
Compare DorkOS-managed and bring-your-own Composio routes.
Raw MCP server
Verify and inventory one preconfigured remote MCP server.
Nango on your server
Keep service login access on infrastructure you control.
When login is off
A local DorkOS installation without login has one local owner. Keep it on a trusted machine and network. Do not expose an installation without login to the public internet.
Program commands still name an agent and can use only that agent's approved connections. Omitting --agent never widens access. Through the supported agent and program paths, a request can ask for access but cannot approve itself.
These controls are boundaries inside DorkOS. They do not isolate other software running as your operating-system user. That software can reach the same local files and credentials that you can. The threat model explains token lifetime, runtime settings, and this same-user limit.
Remove access
Removing an agent's access stops its next action and revokes its notification grants for that connection. Pausing a connection stops local use without deleting it. Disconnecting closes local authority first, then asks the service route to remove its private account.
An external cleanup can remain pending when the service is unavailable. DorkOS keeps the local connection closed while it waits. A request already sent to another service cannot be recalled.