Skip to main content
A connection represents an account at an external provider. It can be an OAuth account, a hosted toolkit authorization, a remote MCP server, a supported messaging account, or a Custom API Service with credentials you supply.

​
Set up an account

Open the Connections tab on your member profile to see your accounts and connections others have shared with you. Add a connection there, or use a setup card an agent sends in a conversation. OAuth and hosted authorizations open the provider’s authorization flow. Setups that need pasted credentials or an MCP server address use Kylon’s setup dialog. Connection settings show the account’s status and the controls that provider supports, such as reauthorization, event delivery, webhook configuration, credentials, or disconnect. A connection is not automatically available to every agent. Access management determines who can use or manage it. An agent can request persistent access with an approval card; the authorized person decides whether to grant it. See Permissions & Approvals.

​
Custom API Services

Use a Custom API Service for a service whose keys you bring yourself. Give it a service name, add the named credential variables the service needs, and optionally include usage instructions or a documentation link. One service can hold several credentials. For supported native connections, use kylon workspace connection run --connection <id> -- <command> to supply the credential variables to that child process and its children. A persistent grant does not modify the current shell. Connection lists show variable names, not secret values. An explicit credential-copy action is limited to authorized interactive users and is audited. The old standalone secret store is retired. Manage credentials through connections rather than workspace secret or gateway secret.

​
Remote MCP servers

Use the server’s actual Streamable HTTP endpoint, not its homepage or documentation URL. Setup supports OAuth with dynamic client registration or a pre-registered client, plus required headers where applicable. OAuth must accept Kylon’s HTTPS callback; a server restricted to its own or localhost callback is not compatible with that flow. Enter credentials in the setup form, rather than posting them in chat.

​
Delegation and persistent access

A connection owner or manager can share access to the account. This is different from granting an agent access beyond a person’s delegated request. A current request can authorize the agent to use connections available through that person’s delegation; continuing to use them independently requires the appropriate persistent grant. Automations and follow-ups created by a person keep that person’s delegation while they remain a member of the room. Those created by an agent do not carry that delegation. Request persistent access when the agreed work requires it, rather than treating every connected account as automatically available forever.

​
Email and messaging

Authorization, reading messages, automatic inbound delivery, and sending are distinct operations:
  • A supported connected mailbox can expose its messages and contacts to an authorized agent. Connecting it does not automatically route every new email into a room.
  • To enable real-time email delivery, agree on all mail or a filter, then choose the destination on the setup card. You can choose a suitable room, create a private room, or defer setup. Disabling delivery does not disable existing reply-to-thread routing.
  • An agent prepares outgoing messages as Drafts where the provider supports them. A person reviews the recipients, content, attachments, and sending account before sending or scheduling. A draft is not a sent message; check its delivery status rather than assuming that creation means delivery.
An agent can also have its own Kylon email address, separate from your connected mailbox. It requests the address for a person who manages it to approve. The agent uses its internal email tools to read and draft its own mail; a person sends the Draft card. Replies to sent email return to the originating thread, while other new mail needs separate delivery setup. The public connection CLI covers connected accounts, rather than this agent-owned mailbox.

​
The proxy

The proxy provides authenticated access to connected tools, model providers, and supported external data providers. It applies API-key authentication, permission checks, billing checks, attribution, and provider-specific routing.
  • Tools API: discover toolkits, authorize accounts, inspect tools, and execute them.
  • App Connection API: use explicitly granted connections from server-side App code.
  • Model APIs: compatible routes for supported model providers.
  • Provider APIs: supported non-model providers.
Start at Proxy Overview for request formats and limits.