Integrations
Connect organization-owned tools without exposing provider credentials to agent processes.
Integrations give selected profiles bounded access to external systems. Organization owners control which provider is connected, which tools or services are enabled, which profiles receive access, and whether the integration is read-only or full access.

Every provider exposes its runtime type, readiness, department and profile grants, access mode, and enabled tools without revealing stored credentials.
Integration Types
| Type | Who Defines It | Examples |
|---|---|---|
| Managed MCP | Reviewed Git catalog and trusted runtime registry | Resend, Exa, Apollo, PostHog, Stripe, GitHub |
| Managed CLI | Reviewed catalog, pinned vendor binary, scoped gateway | Google Workspace |
| Custom remote MCP | Organization configuration with strict HTTPS validation | An organization-owned Streamable HTTP server |
| Trusted local MCP | Agent image and Git profile grants | Structured questions |
Safe Connection Flow
Select
Choose services, tools, profiles, and access mode.
Connect
Provide a write-only credential or complete provider consent.
Resolve
The backend creates a short-lived execution capability.
Act
Reads execute; consequential effects follow action policy.
Credentials
Credential inputs are write-only. The product reports readiness and redacted account information, but it never returns the stored secret. Provider credentials are decrypted only inside the backend gateway for an authorized execution.
Current State and Business Context
Connection state and business meaning are separate:
- The Integrations registry says what is connected and eligible now.
- Organization Context says why the business uses a system, which workflows depend on it, and whether it is primary, fallback, or merely allowed.
- Onboarding sources remain evidence of the business at onboarding time. They do not freeze the organization’s future toolset or prove that a connector is currently ready.
After a connection succeeds, you can optionally choose Add business context. Supply a short purpose, department scope, role, and any existing workflow keys, or choose Not now. Skipping does not roll back the connection. A connected integration without reviewed business meaning appears as Needs business context until the focused repair is approved and reconciled.
Context repair never edits canonical Context immediately. Oblive prepares a bounded update, asks only for missing meaning, and requires human approval before promotion.
Readiness
Readiness is a control-plane assessment; it does not call the provider.
| State | Meaning |
|---|---|
| Ready | Enabled, credentialed when required, and has at least one allowed tool. |
| Disabled | Connection material and tools exist, but runtime use is disabled. |
| Needs credentials | Required connection material or an allowed tool selection is missing. |
| Unavailable | The reviewed catalog/runtime no longer permits this connector. |
Every new run receives the latest eligible inventory. An already-running task is not hot-patched; if authorization changes, its old capability fails and the work restarts from current state.
Start Narrow
Use read-only access and the smallest useful tool or service selection first. Enable full access only when the workflow genuinely requires external changes and the organization’s approval policy is understood.