Whose permissions does a CI-triggered scan run with?

The short version

The job runs as the owner of CYBERLOP_API_TOKEN. It can reach what that person can reach, and nothing else.

How it works in Cyberlop

The footer on Integrations says it plainly: the scan runs with your permissions and group scope. The in-app documentation repeats that the token carries its owner's permissions and group scope.

Two checks apply to each call.

Group scope narrows the list of profiles further. An owner who sees only some profiles can trigger only those. The rest simply do not exist for that token, which is exactly what you want from an account that a pipeline holds.

This design has a practical effect that surprises teams the first time they notice it. If the person who issued the token leaves the team or loses a permission, the pipeline loses it too. Reverse it, and the risk shows. An over-powered account hands a pipeline more access than it needs, and if that token ever leaks, it carries all of that access out with it, into whatever system holds the copy.

What to do next

• Create a user just for automation, with a role that holds ci:trigger, scan:read and access to the right profiles.
• Ask an admin to issue that user's token. See how to get a personal API token.
• Store it as a secret, as in which secrets to add.
• If a call fails, read why the API says no.

Background on roles is in API tokens and permissions.

Related questions

• How do I get a personal API token?
• Which secrets do I need to add to my repository for CI scans?
• Why does my API call return a permission error?
• How do I create a custom role with specific permissions?
• How do I revoke a user's API tokens?

Full tutorial

Cyberlop API tokens and permissions: how to issue and limit them

Step-by-step, with annotated screenshots.

Updated 8 October 2026 · Back to the help centre