Skip to main content
An integrated workspace becomes more useful when it can work with tools people already use. Every integration, however, expands the platform’s attack surface and data-handling responsibilities.

​
9.1 Connector model

Each connector should define:
  • The external service and supported account types.
  • The exact scopes or permissions requested.
  • Which data can be read.
  • Which actions can be performed.
  • Whether actions require confirmation.
  • How credentials are stored and revoked.
  • What is logged and how long records are retained.
  • How errors, expired permissions, and service outages are handled.

​
9.2 Integration categories

Potential categories include productivity suites, document storage, project management, source-code hosting, issue tracking, communication tools, and development environments. The presence of a category in this strategy does not imply that a particular connector has shipped.

​
9.3 Least privilege

A calendar assistant should not need permission to delete a repository. A code-review agent should not automatically receive access to a user’s entire cloud drive. Connector scopes should be limited to the task, and users should be able to disconnect a service without contacting support.

​
9.4 Untrusted content

Files, webpages, emails, code comments, and retrieved documents may contain instructions that attempt to manipulate an AI system. Such content must be treated as data, not as a higher-priority command. The orchestration layer should separate system policy, user intent, and external content, while tools enforce their own permissions.

​
9.5 Extension ecosystem

If Orbit eventually supports third-party extensions, it should provide a documented permission model, version compatibility rules, review procedures, and a way to disable or remove extensions. Extension authors should not gain broad account access merely because their extension is installed.