GitLab is the forge the assistant runs against in production every day: draft MRs, issues, reviews, and a security review of the GitLab instance itself. Through the GitLab agent for Kubernetes it reads your clusters without a kubeconfig on its side and without any inbound path to your API servers. GitHub draft pull requests are built and waiting for their first live write; Forgejo is being added.
Agents produce proposals without knowing the forge. A router picks the client for each repository from your configuration, and a proposal is only published to a repository the configuration positively names. Anything unmatched is refused at emission, and the GitLab client refuses repositories configured for another forge.
The same rule holds on every forge: the assistant opens drafts and never merges them.
A tool that reads a cluster normally needs a kubeconfig with long-lived credentials, and a route to the API server: a public endpoint, a VPN, or an allowlisted static egress address on the tool's side.
For a customer cluster behind a VPN, that is a firewall change and a credential to rotate, per cluster.
The GitLab agent (agentk) runs inside the cluster and
keeps an outbound connection to GitLab's agent server (KAS). The
assistant talks to KAS's Kubernetes proxy with a GitLab token scoped
to k8s_proxy, and builds its kubeconfig in memory.
No inbound port, no VPN, no kubeconfig file. Access is granted in the agent's config file in git, to a project or group the bot belongs to.
On GitLab CE every proxied request runs as the agent's service account, so the agent's RBAC is the assistant's access. It is read-only by contract, plus a few narrow, separately bound extras such as requesting a Flux reconcile.
That RBAC file lives in your deployment repo. The assistant checks it for drift, and any change the assistant itself proposes to it is escalated to human review before an MR is opened.
If both agent replicas land on one node, a single spot reclaim or drain takes the whole KAS context down: your CI deploys and the assistant's reads together. The baseline pins zone and host spread and a PodDisruptionBudget, which the chart has no value for.
Three deterministic reviewers read GitLab through a GET-only client: project access and branch protection, the merged CI configuration of every project, and the runners each project can use. No LLM is involved.
When the bot's own role cannot see an endpoint, it files one "could not review" advisory. A blind review is never reported as a clean one.
The GitHub client reads repositories, pull requests and history, and writes draft pull requests. Writing needs an explicit write token, a writable repository row and a positive config match; without all of them it makes no HTTP call at all.
It is built and tested, and waiting for its first live write. Known gaps: marking a PR ready and assigning reviewers.
A Forgejo repository is read through the same reader as GitHub, with a thin dialect for Forgejo's API. At the same commit it returns byte-identical files to a local clone, and a large tree it cannot page through reads as incomplete, never as complete.
Planned, not built: draft pull requests. Forgejo marks drafts by a
WIP: title prefix, so the writer reads the PR back and
closes it if it did not come out as a draft.
Most forge findings are issues: a committed secret needs rotating,
not a diff. One is mechanical: CI_DEBUG_TRACE left on,
which prints every masked variable into the job log. When the
setting is verbatim in the project's own
.gitlab-ci.yml, you get a draft MR. The full MR is
below.
kind: ClusterRole metadata: name: gitops-assistant-read labels: { …/operator-pack: agentk-rbac } rules: - apiGroups: ["", apps, helm.toolkit.fluxcd.io, …] verbs: [get, list, watch] --- separately bound, separately revocable kind: ClusterRole metadata: { name: gitops-assistant-flux-poke } # patch Flux objects to request a reconcile
topologySpreadConstraints: # zone + hostname, via post-renderer PodDisruptionBudget: minAvailable: 1
main allows force-push access · issueCI_DEBUG_TRACE: "true" CI/CD · draft MR✓ path set identical ✓ file bytes identical ✓ parsed manifests identical ✓ resolved commit identical exit 0 · IDENTICAL
variables: - CI_DEBUG_TRACE: "true" + CI_DEBUG_TRACE: "false"
Illustrative project names; the finding, the verbatim-source check and the single-line flip are what the CI/CD reviewer does today.
gitops-ai/cicd-debug-trace-ledger into main · 1 file · +1 −1CI_DEBUG_TRACE is set to true in this project's .gitlab-ci.yml. With debug tracing on, the runner prints every command and every CI/CD variable, including masked ones, into the job log. Anyone who can read the job log can read the secrets.
This MR sets it to false. Nothing else changes.
The reviewer reads the merged CI configuration, which also contains what comes from includes, parent groups and UI variables. It only proposes a diff after re-reading the project's own .gitlab-ci.yml and finding the setting there verbatim. Had it come from an include or a UI variable, you would get an issue pointing at the source instead.
| Check | Result |
|---|---|
Merged CI config has CI_DEBUG_TRACE truthy | yes |
Present verbatim in .gitlab-ci.yml | yes, top-level variables: |
| Key is unique in the file | yes |
variables: - CI_DEBUG_TRACE: "true" + CI_DEBUG_TRACE: "false" DOCKER_DRIVER: overlay2
Flip is minimal and matches the title. Rotation advice is appropriate. LGTM.
A tool with access to your forge and your clusters has to be boring about both.
CI_DEBUG_TRACE fix as a draft MR