Task-scoped GitHub credential policy

The control gap

The provider token may cover an organization, but the agent action should receive only the repository and tool scope authorized for this task.

The policy decision names the repository resource and verified task before a grant exists. After approval, request the GitHub adapter grant. Endram derives its tool and resource from the stored decision rather than trusting a broader value supplied later. The grant endpoint refuses shadow, pending, denied, expired, or already completed decisions.

The adapter compares the requested repository with the grant resource, consumes the token once, and uses the provider credential held by the server. A changed repository or replay is denied before GitHub. The example currently supports issue creation; it should not be described as a general GitHub credential exchange for merges, administration, or every API.

Keep the installation token or personal access token behind the adapter. The agent receives a one-use Endram grant that names the GitHub operation and repository, not the provider credential itself. That design prevents a permitted issue action from becoming an unobserved branch, secret, membership, or organization action.

Resolve repository identity through the GitHub installation and store owner, numeric repository ID, and installation ID. Names can be transferred or recreated, so a string comparison alone is insufficient for durable high-risk policy. Recheck installation access immediately before execution and reject repositories outside the tenant connection.

Verify negative cases with a fork, a similarly named repository, another organization, a changed issue payload, an expired approval, and two concurrent consumers. The evidence chain should include the canonical repository, task, grant hash reference, GitHub request identifier, created object URL, and provider failure if no issue appears.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "github.create_issue" rather than every operation exposed by the tool.
• Scope the target to one repository approved for the delegated task and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

Task-scoped GitHub credential policy 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: task-scoped-github-credential
match:
  identity_verified: true
  task: release-428
  tool: github.create_issue
  resource: repo:acme/platform
decision: require_approval
approval:
  reviewers: ["repository-owners"]
  expires_in: 15m

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

• Every attempted github.create_issue, including denied requests.
• The exact one repository approved for the delegated task selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?