Exemplo completo
Configure o issues-manager do zero e veja, chamada por chamada, como cada parte da configuração responde.
Este exemplo monta um agente real e acompanha cinco chamadas até o resultado. A empresa usa Keycloak para as pessoas e Google Workspace para parte do time, e conectou o MCP server do GitHub.
O objetivo
O issues-manager ajuda o time de engenharia a cuidar de issues e pull requests. A política da empresa é:
- todo mundo no Keycloak pode usar o agente, menos o Diego, que é de outra área;
- o agente pode listar issues em
acme/payments-apieacme/web; - o agente pode fazer merge, mas só em
acme/payments-api, e só de pull requests com pelo menos duas aprovações e nenhuma mudança pedida; - o agente não pode criar branches.
A configuração
| Parte | Configuração | Página |
|---|---|---|
| Who can delegate | Keycloak customer: 80 de 81 pessoas e serviços, todos menos o Diego | Quem pode delegar |
| Tools | GitHub · list_issues e GitHub · merge_pull_request. Sem create_branch | Tools |
| Regras | Em list_issues: "Payments and web repositories", repository is one of [acme/payments-api, acme/web]. Em merge_pull_request: "Payments repository only", repository is one of [acme/payments-api], e "At least 2 approvals, no changes requested", que lê as revisões do pull request numa context source | Regras |
No grafo, merge_pull_request mostra "2 rules", e uma ligação tracejada vai dela até a context source das revisões. Depois de publicar, a barra mostra a revisão efetiva.
As chamadas
Cada chamada passa pelas três verificações. A primeira que falha define o motivo.
| Chamada | Delegação | Tool | Regras | Resultado |
|---|---|---|---|---|
Alice faz merge de um PR com 2 aprovações em acme/payments-api | ✓ | ✓ | ✓ | ALLOW |
Alice faz merge de um PR com 1 aprovação em acme/payments-api | ✓ | ✓ | ✗ "At least 2 approvals" | DENY · condition |
Bruno faz merge em acme/infra | ✓ | ✓ | ✗ "Payments repository only" | DENY · condition |
release-pipeline cria um branch em acme/web | ✓ | ✗ | — | DENY · no_grant |
Diego lista issues em acme/web | ✗ | — | — | DENY · no_delegation |
O Diego nem chega a chamar: a troca de token dele já é recusada com no_delegation, e o agente não recebe token em nome dele. A linha da tabela mostra o que aconteceria se a delegação fosse revogada depois da emissão do token: a verificação por chamada nega do mesmo jeito.
O que o administrador vê
Cada negação aparece no Investigate com a etapa que falhou e uma ação que leva direto à correção. A primeira chamada negada, no inspetor:
O caminho vem primeiro: delegação, agente, server e tool passaram, e a etapa Rules nomeia a regra que falhou. O resultado diz "Rule not met:" com a regra como frase, e Open the rule, embaixo, leva ao painel da tool no grafo. Nenhum valor fica registrado: o registro não diz quantas aprovações o PR tinha.
A negação do Bruno cita a outra regra, "Payments repository only". Open the rule leva ao mesmo painel. O administrador avalia se o agente deve mesmo fazer merge em acme/infra. Se sim, inclui o repositório na lista daquela regra e publica, e a próxima chamada passa.
O que mudar se a política mudar
| Mudança | Onde | Efeito |
|---|---|---|
| Diego entra na engenharia | Marcar o Diego no painel do Keycloak e publicar | A próxima troca de token dele funciona |
Merge também em acme/web | Incluir acme/web na lista de "Payments repository only" | Os merges em acme/web passam pela regra de aprovações |
| Merge só em horário comercial | Outra regra, com um atributo de horário de uma context source | Todas as regras precisam passar |
Acesso temporário a create_branch | Incluir a tool com expiração | Depois da data, volta a ser no_grant sem ninguém mexer |
| Incidente com o agente | Disable agent | Nenhum token novo, próxima chamada recusada |