Credentials, AI models, and integrations

Secure secrets, select model providers, and connect source control and project management.

Secure credentials

Credentials store provider secrets for reuse without exposing the raw value in normal product responses. Create a named credential, select its provider or purpose, enter the secret, and associate it with the relevant model, integration, or resource.

Secret values are encrypted at rest. After saving, the UI shows metadata rather than the plaintext value.

flowchart LR User["Authorized admin"] --> Save["Credential action"] Save --> Validate["Tenant + role validation"] Validate --> Encrypt["Encrypt secret"] Encrypt --> Store[("Credential record ciphertext + metadata")] Workflow["Authorized workflow"] --> Resolve["Resolve resource context + provider"] Resolve --> Store Store --> Runtime["Decrypt only for runtime request"] Runtime --> Provider["External provider"]

Credential metadata and secret material have different exposure rules. Names, provider types, status, and last-updated timestamps can be displayed; decrypted values should exist only for the shortest runtime path needed to call the provider.

Rotate a credential when it expires or may have been exposed. Dependent workflows can fail until the replacement is connected.

AI models and providers

Venture AI settings define model providers, defaults, and workflow/phase overrides. Organization credentials determine which provider paths can actually authenticate, while agent records can supply a compatible model fallback.

Bring your own supported model-provider key through Settings → Credentials. A usable organization key pays the provider directly for the matching model calls; compute is still accounted for separately. A shared platform credential is a platform-paid path, even when that credential is itself a provider subscription.

If a platform-paid provider is disabled, it is offered only when your organization has its own usable key. Review the provider and saved credential when a choice is unavailable. Model availability, context limits, pricing, and provider behavior can change; use the current selector as the source of truth.

flowchart LR Credential["Organization credential"] --> Provider["Supported model provider"] Venture["Venture defaults"] --> Resolve["Phase resolution"] Launch["Per-run override"] --> Resolve Agent["Agent model fallback"] --> Resolve Provider --> Resolve Resolve --> Log["Resolved config snapshotted on run"]

Resolution follows the most specific valid configuration: a per-launch workflow-phase override can refine venture workflow and global settings. System workflow defaults and a compatible agent model fill gaps. The resolved model still requires a usable provider credential and sufficient context/output limits.

Changing a provider clears the selected model to prevent an invalid cross-provider pair. Active workflows keep their configuration snapshot; changing venture settings affects newly created runs.

See Compute, tokens, and model selection for the complete precedence tree, model-selection guidance, token formulas, prompt caching, and billing relationship.

Source control

Three source-control paths are supported: GitHub, GitLab, and platform-hosted repositories. Platform-hosted repositories are Beta — pull requests, review, and merge work, but there are no provider-side CI checks, and recovery can require support. From the Agent Workspace resource, Owners and Admins can use Export workspace to create a private repository in their connected GitHub account or use an existing empty GitHub/GitLab repository. The export includes workspace history. The platform-hosted workspace stays primary, with two-way sync to your repository. The resource shows sync status, and Owners and Admins can select Sync now. If both sides change in conflict, both versions are kept. No other source-control provider can be connected.

Connections can be scoped to a venture; choose the relevant venture when connecting a provider. Venture resources identify the actual repository.

Use Connect GitHub in Settings → Connections or a chat connection card, authorize access in GitHub, then select the repositories to share with the venture. If your organization requires approval, the card shows that it is waiting for your GitHub organization owner.

For Google Search Console, connect Google and explicitly approve Read Search Console data. This provides read-only Search Console access; other Google permissions require their own approval.

Keep the two layers distinct:

the connection identifies provider credentials and integration state and scope;
the repository resource identifies the venture-owned repository, URL, provider, and workflow context;
the workflow input selects the repository and base branch for one run.

Email accounts

Email is opt-in through a connected email account. Each address belongs to one agent; inbound messages reach that agent’s thread. Owners and Admins can set the account’s sending policy, daily per-contact reply cap, and pause state. Address management on the shared hosted transport requires Organ staff.

Policies range from read-only to requiring approval for every external email, the first email to each address, or sending without routine review. Under the first-email policy, an operator must approve the first outbound email to every external address, including someone who wrote to you first. That approval covers the address across the venture’s accounts and agents. Follow-ups still need approval until the contact sends a human reply on the thread; then replies to approved contacts can send within the configured cap. Scheduled and workflow messages that start an external thread or follow up before a human reply still require review. Under the no-approval policy, established-thread replies can send within the cap. Pending email approvals appear in the venture Inbox.

An agent can withdraw its own email while it is awaiting approval. The thread keeps the withdrawn draft and its reason; withdrawal does not recall a sent email. Outbound message cards show delivery, open, bounce, or complaint information when the provider reports it. A sent status alone does not confirm delivery or that someone read the message.

Human inbound mail that needs a response appears under Needs reply in the venture Inbox and in department email views. Messages to shared and role addresses go to the agent assigned to that address. Messages with no assigned agent appear separately when detected. Ask Organ staff to assign the address so a teammate can receive its messages.

If Organ staff have enabled it for your venture, some incoming emails can start agent work as soon as they arrive. Sending still follows the account’s approval policy. If too many agents are already working, the email may wait for a later scheduled check-in.

Project management

Linear is the only supported integration for task-driven developer workflows. No other tracker can be connected, and workflows that are not task-driven do not need one at all.

Use the providers offered in the current Settings and launch forms as the source of truth. If a provider is not selectable there, it is not supported — do not plan a workflow around it.