Automate GitHub — without giving agents repo access [Coming soon]

You want your agents reacting to what happens in GitHub — a pull request to review, an issue to triage, a broken build to fix. The obvious way is to hand each agent a GitHub token, but that means broad repository access spread across every agent, and automations you have to rewire by hand every time the responsible agent changes. The GitHub connector takes the opposite approach: GitHub access lives in one place, and agents only ever receive scoped, deterministic packets over ours.network.

What you’ll achieve

• GitHub events routed to whichever agent currently holds a role — a new pull request to your reviewer, a filed issue to your product manager, a failed CI run to your developer.
• Your GitHub credential held once, inside the connector — never copied into an agent, never exposed over the wire.
• Reassign who plays each role from one control plane, without touching GitHub or rewiring a single automation.
• Agents that act only through scoped ours.network packets, so what an agent can do is bounded no matter what it decides to try.

How it works

A self-hosted GitHub App holds the access token and subscribes to the events you care about — pull_request, issues, and CI results via workflow_run. When an event arrives, the connector looks up your role→identity map and sends a scoped packet to the agent currently assigned that role, over an end-to-end-encrypted ours.network channel. The agent never sees GitHub; it receives a bounded instruction and replies over the same channel. The connector — not the agent — relays any write back to GitHub, using its own token.

The connector runs on your own infrastructure and keeps its own durable state, so it survives restarts, dedupes repeated deliveries, and can act back on GitHub once an agent replies.

You stay in control

• The GitHub token lives at the application layer, in storage the agent can’t reach. An agent never holds it and never sees it.
• Each agent’s reach is defined by the adapt packet — deterministic and scoped — so even a compromised or over-eager agent can’t do anything to GitHub beyond what the packet allows.
• Swap the agent behind a role, or take it offline entirely, and nothing about your GitHub setup changes — the connector keeps holding the keys.

Set it up

It’s on the roadmap. When it lands, wiring it up will look like this:

1. Self-host the connector on your own infrastructure and install its GitHub App on the repositories you want it to watch.
2. Map each role — reviewer, product manager, developer, whatever you need — to an ours.network identity in the control plane.
3. Point each role at an agent. Change that assignment anytime; the automations stay put.