Worked example
Configure issues-manager from scratch and see, call by call, how each part of the configuration decides.
This example builds a real agent and follows five calls to their decision. The company uses Keycloak for people and Google Workspace for part of the team, and has connected the GitHub MCP server.
The goal
issues-manager helps the engineering team handle issues and pull requests. The company policy is:
- everyone in Keycloak can use the agent, except Diego, who is in another area;
- the agent can list issues in
acme/payments-apiandacme/web; - the agent can merge, but only in
acme/payments-api, and only pull requests with at least two approvals and no changes requested; - the agent cannot create branches.
The configuration
| Part | Configuration | Page |
|---|---|---|
| Who can delegate | Keycloak customer: 80 of 81 people and services, everyone except Diego | Who can delegate |
| Tools | GitHub · list_issues and GitHub · merge_pull_request. No create_branch | Tools |
| Rules | On list_issues: "Payments and web repositories", repository is one of [acme/payments-api, acme/web]. On merge_pull_request: "Payments repository only", repository is one of [acme/payments-api], and "At least 2 approvals, no changes requested", reading the pull request reviews from a context source | Rules |
In the graph, merge_pull_request shows "2 rules", and a dashed link goes from it to the context source of the reviews. After publishing, the bar shows the effective revision.
The calls
Each call goes through the three checks. The first one that fails sets the reason.
| Call | Delegation | Tool | Rules | Result |
|---|---|---|---|---|
Alice merges a PR with 2 approvals in acme/payments-api | ✓ | ✓ | ✓ | ALLOW |
Alice merges a PR with 1 approval in acme/payments-api | ✓ | ✓ | ✗ "At least 2 approvals" | DENY · condition |
Bruno merges in acme/infra | ✓ | ✓ | ✗ "Payments repository only" | DENY · condition |
release-pipeline creates a branch in acme/web | ✓ | ✗ | — | DENY · no_grant |
Diego lists issues in acme/web | ✗ | — | — | DENY · no_delegation |
Diego never gets to call: his token exchange is already refused with no_delegation, and the agent gets no token for him. The table row shows what would happen if the delegation were revoked after the token was issued: the per-call check denies the same way.
What the administrator sees
Each denial appears in Investigate with the step that failed and an action that leads straight to the fix. The first denied call, in the inspector:
The path comes first: delegation, agent, server and tool passed, and the Rules step names the rule that failed. The result reads "Rule not met:" with the rule as a sentence, and Open the rule, under it, leads to the tool panel in the graph. No value is recorded: the record does not say how many approvals the PR had.
Bruno's denial names the other rule, "Payments repository only". Open the rule leads to the same panel. The administrator decides whether the agent should really merge in acme/infra. If so, they add the repository to the list of that rule and publish, and the next call goes through.
What to change if the policy changes
| Change | Where | Effect |
|---|---|---|
| Diego moves to engineering | Check Diego in the Keycloak panel and publish | His next token exchange works |
Merge also in acme/web | Add acme/web to the list of "Payments repository only" | Merges in acme/web are evaluated by the approval rule |
| Merge only during business hours | Another rule, with a time attribute from a context source | Every rule must pass |
Temporary access to create_branch | Add the tool with an expiration | After the date, it is no_grant again with nobody touching it |
| Incident with the agent | Disable agent | No new token, next call refused |