Skip to main content
Automatically enabled when you configure GitLab permissions in your agent workflow.

​
What it does

  • Read repository files, the file tree, commits, branches and tags, and compare two branches
  • Commit several file changes to a branch in one commit, and create and delete branches and tags
  • Open, read, comment on, approve and merge merge requests
  • Create, comment on and close issues, and read labels, milestones, boards and epics
  • Read pipelines, jobs and job logs, and run, retry or cancel them
  • Read and change wikis, snippets, releases, packages and project settings, as the permission groups allow. Safety Controls below lists what always asks
Neo acts as the access token you saved: it sees and changes only what that token’s role allows, and GitLab itself refuses the rest. Use a project access token to keep every agent’s writes in one repository. Neo hides runner, trigger and webhook tokens, application secrets, support PINs and CI/CD variable values in every answer; a repository file is returned as it is. A hidden field reads [hidden by Neo], and Neo refuses a write that sends it back, so a secret is never overwritten with the mark.

​
Choose where each agent works

Name the project and branch in the agent’s instructions, for example “Commit into the folder neo-agents on main in the project my-group/neo-agents”. To keep every agent out of a project, connect GitLab with a project or group access token that cannot reach it.

​
Permission groups

Each group can be Disabled, Read Only or Read / Write, with or without a technician’s approval for changes.

​
Safety Controls

These always ask a technician, whatever the profile:
  • Every Members & Access change except one that only takes access away (removing a member, blocking, banning or deactivating a user), and deleting a user
  • A deploy key, a runner assigned or changed, the CI job-token allowlist, a fork, and a transfer to another namespace (a project moved into a group included), which give access to your code
  • Protected branches, tags and environments, push rules, merge request approval rules and settings, and a pull mirror, which decide what protects your code, and a gate’s action: protecting or unprotecting a branch, a status check’s response, a commit status, approving a deployment
  • Kubernetes clusters and cluster agents, which decide where deployments go, and freeze periods and resource groups, which keep them safe
  • Cloning or moving an issue to another project
  • Package, container registry and Terraform state protection rules, and virtual registries and their upstreams
  • Every change to a self-managed server’s own configuration (Instance Administration), such as Sidekiq queues, instance CI variables, applications, licenses and Geo sites
  • Security settings, such as secret push protection, and security policies, and the server’s application settings, such as required two-factor sign-in
  • A push mirror, a webhook, an integration, an external status check, an export, an offline export and an import (a remote import can replace a project), which move your code or its events in or out of GitLab
  • A project or group update that widens who sees it (its visibility, public jobs, a feature’s access level) changes where its code comes from (pull-mirror settings, the import URL, the CI configuration path), turns off a merge gate (a required pipeline, resolved discussions, status checks, approvals), or loosens who may sign in, join, share, fork or push (required two-factor sign-in, IP restrictions, allowed email domains, sharing and membership locks, default branch protection)
  • Archiving, unarchiving or restoring a project or a group, and deleting one
Every other change, such as a project’s description or badges, follows its group’s own approval setting. Neo never sends these:
  • Creating or rotating an access, deploy or runner token, or an application secret, because the answer is the new credential
  • Terraform state and secure file downloads, which hold secrets in plain text
  • The package-manager protocols (npm, Maven, PyPI and the rest), and file uploads
  • The endpoints only a runner, a CI job token or a pipeline trigger token can call
  • GitLab’s query language (GLQL), GitLab Duo’s AI endpoints, Markdown rendering, cross-resource counters, the activity feeds (events), the to-do list, export downloads, release evidence and Markdown uploads, which read issues, merge requests and code in one call, past the agent’s permission groups
  • sudo, which would run a call as another GitLab user
  • The Search API with a scope other than code (blobs, commits); each list’s own search filter covers the rest, under its own permission group

​
Setup

See Connecting GitLab to Neo.