The Pulse

Entire gives AI agents service accounts for repository access

Entire has introduced service accounts that let AI agents and automated jobs access selected repositories without a human login. Each organization or account can have up to five service accounts across its projects.

AI.info Team · · fact-checked · against 3 sources ↓ · Published 13 Nov 2026

AI agents and automated jobs can now access selected Entire repositories through service accounts rather than a human login, the company said in a Nov. 13 post. The accounts belong to individual projects and can be assigned reader, writer or admin access.

Each organization or account can have up to five service accounts across its projects. The feature works in projects hosted on Entire, not in GitHub mirror projects.

Access within a project

A service account can be given access to an individual repository or every repository in its project, but it cannot reach repositories in other projects. The available roles are the same ones used for people, and Entire recommends granting the narrowest role that allows an account to do its job.

Commands that list a project’s repositories require a grant covering the whole project. The web interface grants access to individual repositories; access to every repository in a project can be granted through the command-line interface, or CLI.

To create an account on the website, someone with permission to manage the project opens the project’s settings, selects service accounts and names the new account. The creation dialog provides an account ID and authentication URL that jobs use to sign in; repository access and a role can then be selected for that account.

Signing in with platform tokens

For platforms that issue OpenID Connect, or OIDC, tokens, a service account can be bound to the platform once. Each job or agent then signs in with its own short-lived token, without a stored service account secret.

GitHub Actions and Cursor are among the platforms that issue those tokens. A binding contains values, called pins, that a job’s token must match, such as a repository name; additional conditions can restrict it to a branch. For a GitHub Actions binding created on the website, the interface supplies a workflow step to add.

The documentation lists other platforms, including Amp, Buildkite, Devin, Google Cloud and Vercel. A service account can hold one binding per platform. Already-issued tokens keep working for up to 45 minutes after a binding is removed, according to the documentation.

Secrets for other platforms

For platforms without OIDC, a service account can instead sign in with a secret stored where the code runs. Secrets last 90 days by default, with an option to set an expiry between 1 and 365 days. Each account can hold two unexpired secrets, allowing a replacement to be created before the old one is removed.

The secret is printed once when it is created through the CLI. Creating secrets through the website is planned, but is not yet available.

The Entire CLI, Git remote and Go SDK exchange the secret for a service account token and renew the token as needed. Other HTTP clients perform the exchange themselves. A token obtained from a secret lasts at most 10 minutes and never beyond the secret’s expiry.