AI Security

Using OIDC and Fine‑Grained Tokens to Secure a Coding Agent’s Access to a Private GitHub Repository

Published 2026-10-01 by AISecAll Editorial

TL;DR: Use GitHub’s OpenID Connect (OIDC) workflow to issue short‑lived, scoped tokens for your coding AI agent. Combine OIDC with fine‑grained repository permissions, store the token only in memory, and rotate/revoke automatically after each job. This gives the agent exactly the access it needs—no permanent secrets, no over‑privileged keys.

Why the access model matters

AI coding agents (e.g., OpenAI Agents, Claude Managed Agents, Replit Agents) often need to read source code, create branches, and push patches. If you grant a static personal access token (PAT) with broad scopes, a compromised agent can exfiltrate the entire codebase or modify production pipelines. The risk is amplified for small companies that rely on a single repository for core IP.

What permissions does a coding agent actually need?

Start by listing the minimal Git operations the agent will perform:

• Read repository contents (code, config files)
• Create a new branch for a fix or feature
• Commit changes and push the branch
• Open a pull request (optional)

From this list you can derive the exact GitHub permission set: contents:read, contents:write, and pull_requests:write on a single repository. Anything beyond that—e.g., admin or repo scope—should be avoided.

How to use GitHub OIDC for short‑lived tokens

GitHub OIDC lets a workload prove its identity to GitHub and receive a token that expires after a configurable short period (typically 5‑10 minutes). The flow works as follows:

1. Configure a GitHub Actions OIDC provider or a custom OIDC identity provider that the AI agent can call.
2. In the provider’s trust relationship, restrict the audience to a specific GitHub repository and limit the permissions claim to the fine‑grained scopes identified above.
3. When the agent starts a job, it requests an OIDC token from the provider.
4. GitHub exchanges the OIDC token for a short‑lived GITHUB_TOKEN that can be used with the REST API or Git over HTTPS.
5. The token lives only in the agent’s memory; once the job finishes, the token expires automatically.

Because the token is never persisted, a breach of the agent’s runtime environment does not expose a reusable secret.

Alternative: Deploy keys and fine‑grained personal access tokens

If OIDC is not available (e.g., the agent runs on a self‑hosted VM without an OIDC provider), you can fall back to two well‑known patterns:

• Deploy keys: Add a read‑only SSH key to the repository. Use it only for cloning; the agent cannot push changes.
• Fine‑grained PATs: Create a token scoped to a single repository with Read and write permissions. Store the token in a secret manager (e.g., HashiCorp Vault, AWS Secrets Manager) and inject it at runtime. Rotate the token weekly and audit its usage.

Both alternatives are acceptable, but they require diligent secret storage and rotation practices—something OIDC eliminates by design.

Putting it together: Step‑by‑step checklist

1. Define the minimal Git actions your agent needs.
2. Choose the token strategy: OIDC preferred; otherwise fine‑grained PAT.
3. Configure the trust relationship in GitHub (Settings → Security → OIDC). Limit the audience to the repository and set the exact permissions claim.
4. Update the agent code to request an OIDC token before any Git operation. Use the Authorization: Bearer <token> header for API calls or configure Git to use the token as a password for HTTPS.
5. Store no static secrets in code or environment files. If you must use a PAT, keep it in a secret manager and inject it only at runtime.
6. Log each token request (timestamp, repository, scopes) in an immutable audit log (e.g., Cloudflare Workers KV with write‑once policy).
7. Monitor for anomalies: sudden spikes in API calls, unexpected branch creations, or token reuse after expiration.
8. Revoke and rotate tokens automatically after each job; for PATs, schedule rotation at least weekly.

Monitoring and revocation

Even with short‑lived tokens, you need visibility:

• Enable GitHub’s audit log for the organization and filter for oauth_application events.
• Send token‑request events to a SIEM or a simple spreadsheet for weekly review.
• Set up an alert (e.g., via Cloudflare Workers AI webhook) that triggers if a token is used outside the expected IP range.

When an anomaly is detected, immediately revoke the offending token via the GitHub API and rotate any associated PATs.

Summary

By leveraging GitHub OIDC, fine‑grained permissions, and in‑memory token handling, small teams can give AI coding agents the exact access they need—no permanent secrets, no over‑privileged keys. Pair this with immutable logging and automated revocation, and you have a supply‑chain‑secure workflow that scales with your AI automation ambitions.