GitHub + governed AI agents
Repository context makes an agent dramatically more useful to an engineering org. It also makes an unscoped agent dramatically more dangerous. Publish the reads, gate the writes, and keep the token in your vault.
Connecting GitHub
| Definition | Import the GitHub REST API specification for the endpoints you want reachable. |
|---|---|
| Credential | Fine-grained personal access token, or a GitHub App installation token. |
| Stored as | A secret:// reference to your own vault. FlozentAi never holds the value. |
Actions teams usually publish
Action names are yours to choose during review — these are the shapes most teams end up with. Anything that writes is confirmation-gated unless you deliberately publish it otherwise.
| Action | Kind | What it does |
|---|---|---|
issue.list | Read | List issues with labels and state. |
pull.get | Read | Read a pull request and its checks. |
issue.create | Write | Open an issue after approval. |
issue.comment | Write | Comment on an issue or pull request. |
What people build with it
- A triage assistant that labels and summarises incoming issues for a maintainer to confirm.
- Release-note preparation from merged pull requests, read-only.
- A support agent that links a customer report to the issue already tracking it.
There is no field in the console that accepts a token or a password. You store the secret in your vault and give FlozentAi a reference; the runtime resolves it inside the execution layer, after the policy decision.
GitHub questions
Why not give the agent a token directly?
Because then the token is wherever the agent is, and every action it takes is attributable only to the token. Going through a connection means the credential stays in your vault and each run is attributable to the identity that started it.
Use cases that involve GitHub
Connect GitHub the governed way.
Import the specification, review what it found, and publish only what you want reachable.