Securing AI Agents That Work Against Your GitHub Repos

There is no "Office GitHub Security" product

Nobody sells a tool under that name. The phrase reads like a search engine blending two separate concerns: securing AI agents in an office, meaning a company's day-to-day deployment, and securing them specifically against GitHub, where most coding agents end up pushing commits or opening pull requests. Treated separately, both halves have real, specific answers, which is what the rest of this page covers.

If you actually meant Microsoft 365 Copilot or another Office-branded assistant, that is a different product with a different security model, built on Microsoft Entra ID and the Microsoft Graph rather than on GitHub's repository controls, and it is covered on this site's companion page about Office 365 AI assistant security. This page is about agents that touch your code, not your documents.

• "Office GitHub Security" is not a real product, so the honest answer treats the two problems separately.
• If you meant Microsoft 365 Copilot, that is Entra ID and Graph permissions, not GitHub controls.
• This page covers agents that read, write or push against a GitHub repository.

The first gate: branch protection, required review and CODEOWNERS

The baseline control for any agent-authored change is the same one you would use for a careless human contributor: nothing merges to a protected branch without a required review. GitHub's branch protection rules let an administrator require at least one approval before merge, and when combined with a CODEOWNERS file, that approval has to come from someone GitHub recognizes as an owner of the code the pull request touches.

A CODEOWNERS file, placed in the repository's .github, root, or docs directory, maps file patterns to the people or teams responsible for them. GitHub automatically requests a review from the matching owners when a pull request touches their files, and branch protection can turn that automatic request into a hard requirement: the merge button stays disabled until one of the listed owners approves. Only one approval from any listed owner is needed, not all of them, so define the file deliberately rather than listing everyone who might plausibly care.

• Branch protection: require at least one approval before a merge is allowed.
• CODEOWNERS: maps file patterns to the people who must be among the approvers.
• One approval from any listed owner satisfies the rule; it does not require unanimous sign-off.

Stopping a pushed secret before it lands

An agent that commits broadly can stage a credentials file along with everything else it touched, and once a secret reaches a remote repository, rotating it is the only real fix. GitHub's secret scanning push protection blocks a push that contains a recognizable secret pattern before it is accepted, rather than finding it afterward. It runs automatically and for free on public repositories; for an organization's private repositories, it is part of GitHub Secret Protection, available on GitHub Team and GitHub Enterprise Cloud, and an organization administrator has to turn it on.

This is worth enabling specifically because an agent will not reliably notice it is about to commit a secret the way a careful human reviewer might. The block happens at the push, which is exactly where an agent's workflow would otherwise complete the mistake unnoticed.

• Push protection blocks a detected secret at push time, not after it is already in the repository.
• Free and automatic on public repositories.
• On private repositories, it needs GitHub Secret Protection turned on by an org admin.

Scoping the credential an agent uses to reach GitHub

If an agent needs to push commits or open pull requests on your behalf, give it a fine-grained personal access token rather than a classic one. A classic token grants access to every repository your account can reach; a fine-grained token is limited to the specific repositories and the specific permissions you choose when you create it, so a leaked token exposes far less.

For automation that runs in GitHub Actions rather than from a developer's machine, OIDC removes the stored credential altogether. The workflow exchanges a short-lived, GitHub-issued identity token for a cloud access token at run time, so no long-lived cloud secret sits in the repository's settings waiting to be copied or to expire unnoticed.

• Fine-grained PAT: scoped to named repositories and named permissions, not your whole account.
• Classic PAT: broad by default, a worse fit for an automated agent.
• OIDC in Actions: trades a stored secret for a token issued fresh on every run.

The two agent models already built into GitHub's ecosystem

GitHub's own Copilot coding agent researches a repository, plans a change, and implements it in an ephemeral cloud environment, but it is scoped tightly: it can only work in the one repository you specify for a task, on one branch, and it opens at most one pull request per task, with a maximum session length of 59 minutes. Existing branch protection and repository rules apply to it like any other actor, and an administrator has to explicitly add it as a bypass actor on a ruleset if it should be exempt from a rule that would otherwise block it.

Anthropic's Claude Code GitHub Action works differently: you install it as a GitHub App with a defined permission set (contents, issues and pull requests, read and write, plus a few more the app's other features use), store an ANTHROPIC_API_KEY or CLAUDE_CODE_OAUTH_TOKEN as a repository secret, and it responds to an @claude mention in an issue or pull request, or to a prompt you give it on a schedule. Before it runs, it checks that the triggering user has write access to the repository and rejects a bot actor unless you explicitly allow it, which stops an agent from being triggered in a loop by another automated process.

Both models are a better fit for agent automation than handing an agent your own personal GitHub login, because both scope what the agent can do to something narrower than full account access, and both leave an audit trail distinct from a human's.

• GitHub Copilot coding agent: one repository, one branch, one PR per task, 59-minute session cap.
• Claude Code GitHub Action: a scoped GitHub App plus a repository secret, triggered by @claude or a scheduled prompt.
• Both check who or what triggered them before running, which a personal login does not.

The second gate: the desktop session that writes the code

Everything above governs what happens once a change reaches GitHub. It does nothing for the step before that, the agent session on a developer's own machine where the code and the commit were actually produced. That is where "secure ai agents desktop" and "secure manage multiple ai agents" point: a company running several coding agents across several developers needs each session confined to its own project, with its own credentials, before any of it reaches a pull request.

Forkbench is a desktop app for the Mac built for exactly that layer. It runs coding agent CLIs, such as Claude Code or Codex, in real terminals, and a Thread can be locked to its folders through the macOS kernel sandbox, keeping other repositories, Documents and ~/.ssh out of reach. Its Vault keeps a GitHub token or model API key in the macOS Keychain and lets a command use it by name, so the value does not sit in the prompt, the command line or the saved transcript.

The limits matter as much as the features. The folder lock is opt-in and does not restrict the network, so a locked session can still send out what it is allowed to read. Without the lock, a session has the same filesystem access the developer running it has. An unpinned Vault key can still be read by the program it was handed to, since that is the point of handing it over. Forkbench governs the folders you lock and the secrets you put in its Vault, not the whole machine, and it does not run on Windows or Linux yet; both are in development with no date set.

• The GitHub-side controls above do not reach the desktop session that produced the commit.
• Forkbench locks a Thread to its project folders and keeps keys in the Keychain, released by name.
• The folder lock is opt-in, does not restrict the network, and Windows and Linux support is still in development.

A rollout checklist

Put the GitHub-side and desktop-side controls in place together; neither one covers the gap the other leaves.

None of these steps require a new vendor relationship. Most of them are settings already available in a GitHub organization's own console.

• Require review on protected branches, and add a CODEOWNERS file for anything sensitive.
• Turn on GitHub Secret Protection and push protection for private repositories.
• Replace any classic PAT an agent uses with a fine-grained token scoped to one repository.
• Use OIDC for CI workflows instead of a stored cloud secret.
• If you use GitHub Copilot's coding agent or the Claude Code GitHub Action, review which permissions you granted the app and who can trigger a run.
• Confine each developer's agent session to its own project folder and keep GitHub and model keys out of files the session can read.