GitHub App bot identity

There are two ways an agent can act on GitHub through AgentValet.

The classic way is a connected human’s OAuth token: the agent’s calls run as you, and GitHub attributes them to your account. That works, but it means the agent is holding a broad, long-lived, human-scoped credential.

The other way is a GitHub App bot identity. The agent acts as a machine account (agentvalet[bot]), and every call runs under a short-lived, narrowly scoped token. This is the least-privilege option, and it keeps agent activity clearly separated from your personal account.

GitHub App bot identity is an early capability. Installing the bot currently involves AgentValet rather than being fully self-serve, and only the organisation’s primary owner sees the bot as an option today. See Availability below.

The install grant is the ceiling

An AgentValet GitHub App is installed onto the repositories you choose. That installation grants a fixed set of permissions, which act as an upper bound:

• Contents: read and write
• Pull requests: read and write
• Metadata: read

Nothing an agent does can exceed that ceiling. It is the maximum, not the per-call grant.

Every call gets its own token

The important part is what happens per call. When an agent acts as the bot, AgentValet:

1. Works out the repository the call targets (from a /repos/{owner}/{repo}/… path) and the single permission its scope needs.
2. Gets an installation token scoped to exactly that one repository and that one permission.
3. Uses it for that call (GitHub tokens last at most one hour).

So even though the installation could touch every repo you selected, a repo-level request is confined to one repo and one permission. Two limits to that: a call that isn’t under /repos/{owner}/{repo} (for example /user or /orgs/…) gets a token covering every repo the installation can reach, still limited to the one permission; and a minted token is kept in the proxy’s memory for up to 55 minutes and reused by identically-scoped calls, rather than minted afresh every time. The bot’s private key never leaves AgentValet’s vault.

How the identity shows up

When an agent acts as the bot, its GitHub actions are attributed to agentvalet[bot] rather than to a human account, and the audit log records that the call used the installation-token identity along with which app and installation it came from. In the dashboard, an agent using the bot carries a small agentvalet[bot] identity badge.

You choose the identity per agent, on the agent’s GitHub permission row, with an Acts as selector. The options are your owner default, any connected human GitHub account, or agentvalet[bot]. Switching identity does not change what scopes the agent holds; it only changes which credential the call runs under.

Availability

• The bot must already be installed for your organisation. The install action exists in the dashboard, but completing it currently requires AgentValet, so this is not yet a fully self-serve flow for every admin.
• Choosing an agent’s Acts as identity is an admin action. Members cannot change it.
• Today only the organisation’s primary owner sees the agentvalet[bot] option in the selector. Other admins will not see it yet.

If you want GitHub App bot identity enabled for your organisation, contact AgentValet.

Next

• Use a GitHub App bot identity: the dashboard steps
• Agent identity
• Scopes & permissions