A connector links Kaer to a service you already use — GitHub, Slack, Google services and more — so the operator can read from it and act on it as part of real work: reviewing a repository, posting a summary to a channel, checking a calendar.
Every connection is an official one, made with a scoped, revocable token. The operator holds exactly the access you granted, nothing wider, and you can withdraw it whenever you like.
How connecting works
- Open Settings → Connectors and pick the service.
- Sign in to that service and approve the access it asks for.
- The connector appears in your list, and the operator can start using it in turns, workflows, and automations.
The approval step is the one that matters. The scopes you grant during sign-in are the ceiling on what the operator can ever do with that service — it cannot quietly acquire more access later.
Widening access is always a deliberate act you take on this page, by re-authorising with more scopes.
What using one looks like
Once connected, connectors simply show up in the work. A turn that needs GitHub and Slack reads like this:
You Summarise the open pull requests in acme/site and post it to #eng.
Blob Using GitHub (read) and Slack (post message)...
3 open PRs summarised. Draft ready for #eng — approve to post?
You Approve.The operator used only what its grants allow, and the outbound message still paused for sign-off. Scopes and approvals are separate layers, and both apply.
Grant the least, widen later
A good default is to connect with the narrowest scopes that cover what you actually want done, and widen only when a real task needs it.
A worked example: you connect GitHub so the operator can review a repository. Read access is enough — summaries, code questions, and reviews all work. Two weeks later you want it opening pull requests, so you return to Settings → Connectors and re-authorise with write access. The upgrade takes a minute, and for those two weeks the operator could not have written to your repositories even by accident.
Disconnecting
Disconnect any connector, any time, from the same page. Disconnection revokes the token — the operator loses access immediately, and anything that depended on the connector (a workflow step, an automation) will stop working rather than carrying on with stale access.
When a connector stops working
Grants can lapse from the other side too: you might revoke Kaer's access from the service's own security settings, or an organisation admin might rotate credentials. When that happens the connector stops working rather than degrading silently. Reconnect from Settings → Connectors to restore it, granting scopes again as you did the first time.
Good to know
- Which services are available? GitHub, Slack, Google services and more — the full list is on the Connectors page itself.
- Does connecting spend credits? No — connecting is just a grant. The agent work that uses a connector is metered as usual; see Billing and Usage.
- How does this relate to approvals? Scopes bound what the operator can touch; approvals gate when it acts. Destructive or external actions still pause for your sign-off even inside a granted scope — see Privacy and Safety.
- What about email? Mailboxes connect through Mail AI with Google sign-in — the same grant-and-revoke model, managed from Mail → Settings.