GitHub controls for AI agents

The control gap

A coding agent that can read issues may share a token that can also merge code or alter repository protections.

GitHub authority spans organizations, repositories, branches, pull requests, workflows, environments, and administration. Normalize those resource levels instead of treating the token or application installation as one permission. Reading an issue, drafting a comment, creating a branch, merging protected code, altering Actions, and changing branch protection warrant different policies and owners.

Endram’s native provider adapter currently proves one narrow execution path: a one-use grant for `github.create_issue` on the repository bound to the decision. Other GitHub actions can still be authorized through the runtime API with caller-recorded execution evidence. Marketing and evaluation should keep that distinction visible until each server-side adapter has exact-scope, replay, failure, and outcome tests.

What good looks like

Routine GitHub work continues automatically while sensitive actions are denied or held for a named reviewer.

• Classify read_issue and comment_issue separately from merge_pull_request and change_branch_protection.
• Scope policy to organization, repository, branch instead of granting one undifferentiated GitHub capability.
• Require a code-owner or security approval for merges and branch-protection changes.
• Preserve the delegated user, agent, request payload hash, decision, reason, and policy version.

A production workflow

1. The agent asks Endram to evaluate a GitHub action before execution.
2. Endram matches the agent, delegated user, action, and target organization.
3. Low-risk requests proceed; sensitive requests create a time-bound approval.
4. The approved request executes once, and its outcome is attached to the original decision.

A policy you can test

GitHub high-impact approval is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: github-high-impact
match:
  tool: github
  action: ["merge_pull_request", "change_branch_protection"]
  environment: production
decision: require_approval
approval:
  expires_in: 15m
  reviewers: ["security-on-call"]

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• A searchable record of attempted read_issue and change_branch_protection operations.
• The exact organization and branch targeted by each request.
• Which policy version matched and why the request was allowed, denied, or escalated.
• Who approved the action, when approval expired, and whether execution succeeded.

Buyer checklist

• Which GitHub actions must never run without a human?
• Can policy restrict individual organization or repository or branch?
• How are user delegation and service credentials represented?
• What evidence will incident response need after an unexpected action?