Monorepo Agent Security: Limit the Blast Radius

By Lazar Milicevic · Published October 24, 2026 · 10 min read

You gave a coding agent access to your repo so it could ship faster. Now one stolen login, or one compromised service the agent trusts, could expose everything that identity can touch, and your branch protections won't stop it from reading any of it. This is the same shape as the incident Hacktron described in OpenAI's environment, and the fixes are mostly boring credential hygiene you can apply this week.

What actually happened at OpenAI (and what didn't)

According to Hacktron, researchers went from a bug in OpenAI's community forum to OpenAI's internal GitHub monorepo in less than 72 hours, opened one harmless pull request, and stopped. That "72 hours" is Hacktron's own estimate, repeated by VentureBeat and others, so treat it as approximate.

Per Hacktron's write-up, the chain looked like this:

1. A HEIF image upload triggered a libheif heap overflow, giving remote code execution on the forum.
2. A separate flaw in OpenAI's SSO let the compromised forum take over the ChatGPT and Codex accounts of users who had logged into it, with no further interaction.
3. The researchers took over an employee account whose Codex environment was connected to OpenAI's GitHub organization.
4. Using that employee's Codex, they opened PR #1186742 in the internal monorepo openai/openai as proof of access.

Hacktron says it opened one harmless PR as proof of access and stopped testing around 15:30 UTC on July 25, 2026. OpenAI's account differs slightly: it told the Wall Street Journal, as relayed by Quartz, that its review found "limited reads" of private-repository metadata and code. Both statements are on the record, and I'm not going to pick between them. OpenAI also said it narrowed permissions on community sign-in tokens and revoked affected tokens and sessions.

Two details matter for everything below:

• The root problem wasn't the forum software. Hacktron called the escalation an OpenAI identity issue, not a Discourse flaw. Any first-party or third-party service using the same SSO could have yielded the same access (The Hacker News).
• The pivot ran through an AI tool's connectors. Because people can connect services to Codex and ChatGPT, Hacktron wrote that the theoretical access scope included GitHub, Slack and email.

Some things I'm deliberately not leaning on: Hacktron mentions a broader campaign around libheif whose details I haven't verified, and commentary like "anyone can do this for $200 a month" is opinion. The bounty reportedly paid was $6,500, and per SOFX OpenAI said it covered the SSO finding only, since the forum was out of scope for its Bugcrowd program. It wasn't payment for "the whole breach."

Why monorepos change the math for agents

A monorepo isn't insecure. Erik Avakian of Info-Tech Research Group says monorepos are not dangerous in themselves; the issue is the concentration of risk. If an identity has broad access, the blast radius can be much larger than people realize.

The practical mechanics, per VentureBeat's reporting:

• GitHub Apps can be limited to selected repositories, but those permissions apply at the repository level. In a monorepo, that means there are no separate read boundaries between directories.
• Branch protections and code-owner reviews limit what gets merged, not what the identity can see.

So if your single repo holds the marketing site, the billing service, the infrastructure code and a folder of customer-data scripts, an agent credential with access to the repo can read all of it. A code-owner rule on /billing doesn't help with reads.

Coding agents raise the stakes because their credentials tend to be broad and persistent. A human logs in, does something, and logs out. An agent often holds a long-lived token so it can run unattended. That token is the real asset an attacker wants, and in the OpenAI case the equivalent asset was a connected GitHub integration sitting behind an account that could be taken over.

If you're a solo founder, you may think this is an enterprise problem. It's the opposite. Small teams are far more likely to have one repo, one personal token, and one machine where everything is logged in at once.

Start with the credential, not the agent

Avakian's advice is the most useful sentence in the whole story: start with the credential the coding agent uses, not with the agent. That means identifying whether it's an OAuth token, a GitHub App, a service account, a personal access token, or an SSH key, then asking what that credential can reach. He recommends dedicated non-human identities, short-lived credentials, and the narrowest repository permissions possible.

Here's how the common options compare, based on GitHub's own docs:

I'm not stating a specific maximum lifetime for fine-grained PATs here. Your organization's token policy can change what's allowed, including whether tokens without an expiry are permitted, so check GitHub's current docs and your organization's settings, and set a short expiry regardless.

The pattern to aim for: a dedicated GitHub App (a non-human identity) installed on only the repos the agent needs, minting hour-long tokens on demand. If that token leaks, the attacker has at most an hour and at most those repos.

Mint short-lived, repo-scoped tokens

Here's the call that does the narrowing. You authenticate as the App, then request an installation token restricted to named repositories and minimal permissions:

# 1. Build a short-lived JWT for your GitHub App (app ID + private key).
#    Use your preferred JWT tool; the key never lives in the agent's environment.

# 2. Request an installation token scoped to ONE repo with read-only contents
#    and the ability to open pull requests.
curl -s -X POST \
  -H "Authorization: Bearer $APP_JWT" \
  -H "Accept: application/vnd.github+json" \
  api.github.com \
  -d '{
    "repositories": ["client-a-site"],
    "permissions": {
      "contents": "read",
      "pull_requests": "write"
    }
  }'

The repositories parameter and the one-hour expiry are documented behavior. The specific permission names above are an example; confirm the exact set your workflow needs against the current API docs.

A small wrapper script can fetch the token right before an agent session and export it for that session only. The long-lived private key stays on a separate machine or in a secrets manager, never in the agent's shell.

import os, subprocess, json

def fresh_token(repo: str) -> str:
    # mint_token.sh wraps the curl above; the private key lives elsewhere
    out = subprocess.check_output(["./mint_token.sh", repo])
    return json.loads(out)["token"]

env = {**os.environ, "GH_TOKEN": fresh_token("client-a-site")}
subprocess.run(["claude"], env=env)  # token dies on its own within the hour

Split the repo, or split the identity

A monorepo gives you no read boundaries inside it. You have three honest options:

1. Split sensitive code out. Secrets-adjacent code (billing, infra, anything touching customer data) goes in its own repo. The agent identity for day-to-day feature work simply isn't installed there.
2. Keep the monorepo, accept the read scope, and shrink everything else. If you can't split, assume the agent can read the whole tree and compensate with short-lived tokens, no connectors beyond the repo, and no secrets committed to it.
3. Use a fork or mirror for agent work. The agent works on a mirror that excludes sensitive directories, and a human pulls reviewed changes into the real repo.

For a small team, option 1 is usually the cheapest. It's a one-time refactor, and it makes every future credential decision easier. The tradeoff is real: you lose some of the cross-codebase convenience that made the monorepo attractive in the first place. That convenience and that exposure are the same thing.

Treat agent connectors as part of the attack surface

The OpenAI chain didn't end at "forum bug." It ended at an employee's AI account that had a GitHub integration attached. The lesson isn't specific to Codex: every connector you attach to an AI tool (GitHub, Slack, email, drive) becomes reachable by anyone who takes over that account.

A short audit you can do in an afternoon:

• List every connected service on every AI tool account you and your team use. Revoke anything you don't actively use.
• Separate accounts for agents and for humans. Don't give your personal ChatGPT or Claude login the keys to production repos.
• Keep email and chat connectors off the same identity that can open PRs. If one account is taken over, the attacker shouldn't get your inbox and your code in one move.
• Check SSO scope. If a third-party service signs people in through the same identity provider as your AI tools, a bug in that service is a bug in your perimeter. That was the exact failure in this story.
• Enable MFA and review active sessions on AI tool accounts, and know how to revoke all sessions at once. OpenAI's response was to revoke affected tokens and sessions, and you want that muscle available.

For agents that call tools over MCP, the same logic applies: each MCP server is a credential and a permission set. Give each one the narrowest token that works, and don't run one all-powerful server for everything.

Limits that hold when the credential leaks

Assume a credential will eventually leak. Design so the damage is bounded:

• Bound what it can write. Agents open PRs; humans merge. Keep branch protection and required reviews on. They don't prevent reads, but they prevent an attacker from shipping code through your agent.
• Keep secrets out of the repo. Anything committed is readable by any identity with repo access. Use a secrets manager and inject at runtime. Scan history for keys that slipped in.
• Run agents in a sandbox. A container or VM with only the checked-out repo and a single scoped token. No access to your home directory, SSH agent, or cloud CLI credentials. Check the official Claude Code documentation for which isolation and credential options currently exist, since those docs change quickly, instead of trusting a copied snippet.
• Log everything the agent does. At minimum: which token, which repo, which commands, which PRs. If you can't answer "what did this credential touch?" after an incident, you can't scope the cleanup.
• Alert on odd PRs. A new PR from an agent identity at 3 a.m. against a repo it normally never touches should page someone. Even a simple GitHub Actions or webhook check that posts unusual activity to a Slack channel beats nothing.

A minimal audit-log pattern for your own wrapper:

# agent-session-log.yaml (one entry per session)
session_id: 2026-10-24T09:14Z-a81f
identity: gh-app/agent-worker
token_expires_in: 3600
repos_granted: [client-a-site]
permissions: { contents: read, pull_requests: write }
prs_opened: [client-a-site#212]
commands_run: logged-to ./logs/a81f.jsonl

None of this is exotic. It's the same least-privilege thinking you'd apply to any contractor, applied to something that works faster than a contractor and never gets tired.

A one-week hardening checklist

If you only do one thing from this post, replace any classic PAT or long-lived SSH key your agent uses. If you have a week, work down this list:

1. Day 1: Inventory every credential your agents use (OAuth tokens, Apps, service accounts, PATs, SSH keys) and what each can reach.
2. Day 2: Revoke classic PATs. Replace with a dedicated GitHub App or, at minimum, fine-grained tokens scoped to named repos with short expiry.
3. Day 3: Audit connectors on all AI tool accounts. Remove unused ones; split agent identities from personal ones.
4. Day 4: Move secrets out of repos. Scan history.
5. Day 5: Sandbox agent sessions; strip ambient credentials from the environment they run in.
6. Day 6: Turn on logging and a basic alert for unusual agent PRs.
7. Day 7: Decide whether sensitive code should leave the monorepo. Write down the decision either way.

What this won't solve: a vulnerability upstream of your control, like the identity flaw in this story. You can't patch someone else's SSO. What you can do is make sure that when the next one lands, the token an attacker grabs is expensive to use and cheap to revoke.

Where this leaves your setup

My approach is to look at credentials before prompts: which identity does the agent run as, which repos can it reach, and what lands in an audit trail.

If you do one thing after reading this, write down your own credential inventory, even if it's a messy list. It's the fastest way to see what a single leaked token could reach today.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.