Integrations · 09

GitHub

Govern what your agents may do in selected repositories. Your organization's GitHub access never reaches the agent at all.

How it works

Your organization connects GitHub and selects which repositories are governable. A connected provider does not mean every repository. Enrollment is explicit.
Your policy names the repository actions the agent may request. The supported families are repository, content, issue, and pull-request actions.
When an agent's governed action is allowed, Keydris performs the operation using the organization's connected access. The agent never receives that credential. It asked for an outcome, not a key.

A working policy fragment

policy fragment · github branch

actions:
  - allow: github.read_file, github.list_issues
    where: repo in [acme/api, acme/web]
  - require_approval: github.merge_pull_request
  - reject: github.delete_repository
default: reject

github.read_file { repo: acme/api }

repo enrolled · action supported · policy permits

ALLOW

github.merge_pull_request { repo: acme/web, pr: 214 }

held · the approval prompt renders in the agent's harness

APPROVAL REQUIRED

github.read_file { repo: acme/secrets-ops }

repository not enrolled · not governed, not reachable through Keydris

REJECT

Boundaries to plan around

Verified behavior

Not every GitHub operation is supported for governance. Confirm the supported action list in the console for the current release before you build a workflow around it. Known planned, not yet executable:□ github.create_branch · planned□ github.dispatch_workflow · planned□ github.create_release · planned

Take care

An allowed action can still fail at GitHub: permissions, branch protections, and rate limits on the GitHub side apply as always. The audit record will show decision: allow with the provider outcome, distinctly.