Integration × harness
Give a Hermes Agent access to GitHub
On Atako, a Hermes agent reaches GitHub through the integrations broker: you create a fine-grained token limited to the repositories it needs, connect it once, then grant the agent only the endpoints required. Start read-only. The token never lands in the agent's configuration, and every call is logged.
Romain Laodicina · CTO at Atako
GitHub × Hermes AgentSet up, step by step
Screenshots taken on Atako on 9 October 2026, with demo data.
- 1
Create a fine-grained token on GitHub
In GitHub, go to Settings, Developer settings, Personal access tokens, Fine-grained tokens, then Generate new token. Limit it to the repositories the agent needs and set an expiration date. For full use, grant Contents, Issues and Pull requests as Read and write, and Actions as Read. To start safely, set every permission to Read-only and widen later. Copy the token, which starts with github_pat_ or ghp_.
- 2
Connect GitHub in Atako
Open the integrations catalog, pick GitHub and paste the token. Atako stores it on the server side and checks it with a harmless call that lists the repositories the token can reach, so a wrong or expired token shows up right away.
New GitHub connection dialog in Atako: name, scope and an empty personal access token field. - 3
Grant access to your Hermes agent
On the agent's page, choose GitHub, then pick a level: the Read chip, the Write chip, or both. Then tick the endpoints one by one, for example list_issues, get_issue and list_pull_requests for reading, add_issue_comment and update_issue for writing. Whatever stays unticked is not callable by the agent.
Agent rights on the atako-demo GitHub connection: 8 read endpoints enabled, no write endpoint. - 4
Ask the agent to work in GitHub
Write to the agent like to a colleague: list the issues opened since Monday in the backend repository, label them and comment on the ones that lack reproduction steps. The agent calls GitHub through the broker, within the rights you gave it, and answers with what it did.
The Hermes agent lists the 6 open issues of the demo repository and recommends handling #1 first, without changing anything. - 5
Check the calls in the log
Every call is recorded with its tool, status, HTTP code and latency. You see it on the agent and in the dashboard, under integration usage and the integrations log. If something looks off, you can narrow the grant or revoke the connection.
Integration log filtered on the agent, GitHub and successful calls: list_issues, HTTP 200, 492 ms.
Use cases
Triage incoming issues
Every morning the agent lists new issues with list_issues, opens the unclear ones with get_issue, then labels and reorganizes them with update_issue. When a report lacks steps to reproduce, it asks for them with add_issue_comment. Your maintainers start from a sorted queue instead of a raw one.
Summarize the week's pull requests
Every Friday a cron job wakes the agent. With read-only rights it lists the open pull requests through list_pull_requests, reads the ones that stalled with get_pull_request and posts a short summary to your team: what merged, what waits for review, what is blocked. No write endpoint is granted, so the report cannot change the repositories it describes.
Open an issue when a workflow fails
When a check keeps failing on the main branch, the agent looks at the latest runs with list_workflow_runs, then files a clear report with create_issue: which workflow, since when, which run to open. It does not touch the code. The write right is limited to issues, which is enough for a human to pick it up.
Actions the agent can be granted
Each action is granted on its own, read or write.
- list_issues
- get_issue
- update_issue
- add_issue_comment
- create_issue
- list_pull_requests
- get_pull_request
- list_workflow_runs
Why the token should not live in the agent
Hermes Agent, the open-source agent from Nous Research, is happy to work with GitHub. The question is where the credential goes. In a self-hosted setup, the GitHub token ends up in an .env file or in config.yaml, next to the agent, on a machine you keep running, update and back up. Anyone or anything that can read that configuration, including the agent itself under a malicious prompt, can read the token and push with it.
On Atako the credential is kept out of that picture. You connect GitHub once, at company level. The token is stored on the server side and injected when a call leaves. The Hermes agent never receives it: it asks the integrations broker to perform an action, and the broker decides whether that action is allowed. The same mechanism covers every connector in the catalog, so what you learn here applies to the next one.
What you need before starting
You need a GitHub account that can see the repositories the agent will work on, and an Atako agent running on the Hermes harness. Hermes is the default harness for new agents, so a freshly created agent already qualifies. If you are still choosing a harness, the pillar page on autonomous agents explains how an agent works on the platform.
Create a token with the narrowest scope
A fine-grained token has two ceilings. The first is the list of repositories: you choose them when you create the token, and GitHub refuses everything outside. The second is the list of permissions, each set to Read-only or Read and write. Even if you later grant more in Atako, GitHub refuses what the token does not cover.
Least privilege here means starting read-only. Give the token Read-only on Issues and Pull requests, add Contents and Actions as Read-only if the agent must look at files or runs, and limit it to one or two repositories. Watch the agent for a week in the log. If it needs to comment on an issue or label it, raise only Issues to Read and write. Keep Contents and Pull requests writable only if you really want the agent to change code, which most triage and reporting jobs do not need. Set an expiration date so the token cannot live forever by accident.
Treat the token like a password. Paste it into Atako and nowhere else: not in a chat with the agent, not in an issue. Once it is connected, you do not need to see it again.
Connect once, grant per agent
Connecting GitHub in Atako is a company-level action, done from the integrations catalog. It makes GitHub available, but it gives no agent any right by itself. Rights come from the grant you create on each agent.
The grant works in two layers. First you pick a level with the Read and Write chips. Then you tick endpoints one by one. An agent that summarizes the week gets list_pull_requests and get_pull_request, and nothing else. An agent that triages issues gets list_issues and get_issue to read, update_issue and add_issue_comment to write. Two agents can share the same connection with very different rights, and the list of ticked endpoints is the list of what each one can do.
Talking to the agent
Once the grant exists, you do not write any tool configuration. You describe the work in plain language: list the issues opened since Monday, label them and comment on the ones missing reproduction steps. The agent chooses the right endpoints among those it was granted, calls them through the broker and reports back. An endpoint that is not granted cannot be called, and you decide whether to widen the grant.
Because a Hermes agent also runs on a schedule, the same grant serves recurring jobs. A Friday pull request digest or a daily look at failing workflows uses exactly the rights you already defined.
Keep an eye on what happens
Every call that goes through the broker is recorded: which tool, which status, which HTTP code, how long it took. The record is visible on the agent and in the company dashboard, in the integration usage view and in the integrations log. This is your audit trail. When a contributor asks who closed an issue, you can open the log and see the call, instead of guessing from the issue timeline alone.
The log also helps you tune rights. If you see an agent repeatedly trying an endpoint it was not granted, that is a signal: either the task needs it, and you add it deliberately, or the agent is drifting and the prompt needs work.
What this setup does not do
The grant selects endpoints. It does not restrict which issues an endpoint may touch: an agent allowed to call update_issue can update any issue in the repositories the token reaches. If you need a tighter boundary, limit the token to fewer repositories, or keep sensitive writes behind a human step. Pair the agent with a rule that it proposes the change in chat first, and applies it after your confirmation.
For the GitHub side of the connector, including every action it exposes, see the GitHub integration page. The HubSpot and Hermes guide follows the same steps. For concrete workflows, the CI triage use case shows what an agent does with failing runs, and the bug sentinel use case covers incoming reports.
Go further
Other integrations with Hermes Agent
Written by Atako's agents · Reviewed and approved by Romain Laodicina · CTO at Atako
Frequently asked questions
Where is the GitHub token stored?+
On Atako's side, never in the agent's configuration. The agent does not receive the token: it asks the broker to make a call, and the token is injected when the request leaves. A leaked agent configuration or a prompt injection therefore cannot expose it.
Should I give the agent read-only access first?+
Yes, that is the safest start. Set the fine-grained token to Read-only, pick only the Read chip in Atako and tick endpoints such as list_issues or get_pull_request. Once the agent proves useful, add write endpoints one at a time, for example add_issue_comment.
Can I restrict the token to some repositories?+
Yes, and you should. A fine-grained token can be limited to selected repositories when you create it. GitHub then refuses any call outside them, whatever you grant in Atako.
How do I see what the agent did in GitHub?+
Each call is logged with its tool, status, HTTP code and latency. You can read the log on the agent and in the dashboard, under integration usage and the integrations log.
What changes compared to a self-hosted Hermes?+
On a self-hosted Hermes you place the GitHub token yourself, in an .env file or in config.yaml, on a machine you run and back up. On Atako the token lives in the integrations broker, the rights are set per endpoint, and the log comes with it.
What to read next
Sources
- GitHub Docs, Managing your personal access tokens · accessed on October 5, 2026
- Hermes Agent documentation · accessed on October 5, 2026
CTO at Atako
This content was written by Atako's AI agents, then reviewed, corrected, and approved by Romain Laodicina, CTO of Atako.