Tbench AIActions
Client loginTry free

Actions / Connected organization

Your tools. A connected execution trail.

Keep GitHub workflows or an approved Tbench execution policy. Add authorized project context and company identity without moving business rules into the runner platform. A free trial preserves provider authorization and organization approval.

Open organization integrations
Workflow overview4 steps

Keep the workflow you know

  1. Start with a repositoryPrivate code, approved scope
  2. Choose a compatible jobYour existing workflow steps
  3. Run on an enrolled deviceEligible capacity, or queued
  4. Inspect the resultLogs and reports on GitHub
push → queue → run → report
Execution flow

Link the requirement to the work.

  1. Your Tbench operator registers the Atlassian OAuth application and its fixed callback. Secrets stay in server-side secure configuration.
  2. An organization owner or administrator opens Integrations and authorizes the Jira/Confluence sites they can access.
  3. Select a site, an approved GitHub repository and a ticket or page. Optionally associate a PR number or workflow run ID.
  4. Save metadata only, or explicitly consent to sharing the selected title/description snapshot with active organization members.

Links record the provider resource, revision and snapshot hash. A user-entered PR/run association is a reference, not a verified GitHub conclusion. The repository’s tests, checks and review process remain responsible for business acceptance.

The connector requests read-only provider scopes. It does not edit tickets, transition Jira status or submit Confluence content. Disconnecting stops retrieval and revokes linked context inside Tbench; you can also revoke the authorization grant in your Atlassian account.

Let your company handle sign-in.

Corporate OIDC sign-in supports statically approved Entra ID, Okta, Google Workspace and compatible providers. Your operator configures the exact tenant, issuer, client and callback, then links the provider’s subject to an existing approved Tbench client membership.

Open company sign-in and enter the workspace ID your administrator supplies. Authentication and MFA happen with the company provider. Tbench checks the issuer, signature, audience, nonce and the single-use browser-bound login state before creating a session.

An email-domain match does not create or link an account. Company sign-in does not grant GitHub repository access, change a contributor’s role or enroll their computer. For SAML-only providers, use an organization-approved OIDC bridge; native SAML is a separate integration.

Remove access without expanding authority.

The scoped SCIM lifecycle endpoint can list explicitly linked existing users and deactivate an operator-approved non-administrative membership. Deactivation revokes that account’s Tbench sessions. It does not create users, reactivate accounts or grant organization roles.

Your operator issues an expiring, separately revocable SCIM credential for one organization. GitHub membership, external provider grants and enrolled worker credentials have separate lifecycles: review and revoke those through their respective controls during offboarding.

A read-only context interface for agents.

The MCP-compatible HTTP endpoint exposes list_context_links and get_context_link. Both return organization-scoped metadata only. They do not retrieve repository source or ticket bodies, run commands, dispatch pipelines or modify project tools.

POST https://app.tbench.in/api/actions/integrations/mcp
Content-Type: application/json
Authorization: Bearer <15-minute metadata-only MCP credential>

Generate a metadata-only credential in Integrations, then use a client that supports authenticated HTTP MCP and securely supplies that credential. The credential expires after 15 minutes and cannot sign in or dispatch jobs. Browser login cookies are HTTP-only and are not exported from the dashboard. Automatic OAuth discovery for external MCP clients is separate from this initial authenticated interface.

MCP is a tool-access protocol, OIDC authenticates people, and SCIM manages lifecycle. Adding one does not replace the others. Treat any retrieved text as untrusted data, never as permission to execute a workflow or approve a merge.

Choose what leaves the organization.

Cloud connector requests pass through Tbench’s hosted backend to the authorized provider. Metadata-only mode avoids storing ticket and specification content; explicit snapshot sharing sends and stores the selected context in the organization’s Tbench workspace.

Do not use that mode for content your policy requires to remain exclusively in your internal network. A customer-hosted connector is a separate deployment option to design and qualify. External model APIs receive whatever a workflow sends to them.

Slack/Teams alerts, additional task trackers, automatic ticket updates and a customer-hosted connector are extension work, not connected services activated by this guide.

MacBook host support and native Apple builds.

The next source profile distinguishes the Mac host from the job environment: Intel Macs host Ubuntu x64 jobs; Apple Silicon hosts native Ubuntu ARM64 jobs through Docker Desktop. ARM64 labels end in -arm64; existing unsuffixed labels remain x64. There is no silent architecture emulation.

The Mac host release must pass the real-device install, execution, cancellation, sleep/wake, network-loss and cleanup checklist before general download. The device setup guide shows release availability separately from source capability.

Native macOS/Xcode/iOS jobs require a disposable macOS execution backend on Apple hardware. A Linux Docker runner cannot run them. Native Apple jobs and Developer ID-signed/notarized installers remain separate release gates; do not run CI directly in a developer’s logged-in Mac session as a shortcut.