How do I limit which hosts the Git token is sent to?

Steps

This list is a safety fence around your token.

STEPS

Why it matters

Anyone who can create a target can type any repository URL. Without a fence, a token could travel to a host you never meant to trust. The allowed hosts list stops that. The token clones private repositories over HTTPS and is only ever sent to the hosts you list.

Good to know

Use bare domains such as git.example.com, with no path and no scheme. The field's own example shows two domains with a comma between them.

A repository on a host that is not listed gets cloned without the token. Cyberlop treats it as public. That clone will fail if the repository is private, which is a useful sign that the host is missing from your list.

Add a host when your team starts using a second code host, or when you move a repository to a new domain. Remove one when you retire it. Keep the list short.

Personal tokens work alongside this list. Read which token a scan uses first if you want the order. To set up the token itself, follow the organisation token steps.

The token field stays blank after you save because the value is never shown again. That is normal.

Review the list each quarter, or whenever your team changes tools. A host that nobody uses any more is a place where a token could travel for no good reason, and an hour spent tidying the list is a cheap form of insurance. Keep a note of who approved each entry so audits go smoothly.

Related questions

• How do I add an organization Git token for private repositories?
• How do I check that my Git token works?
• How do I remove the organization's Git token?
• What permissions should my Git token have?
• If both I and my organization have a token set, which one does a scan use?

Full tutorial

Git access in Cyberlop: set a read-only token and allowed hosts

Step-by-step, with annotated screenshots.

Updated 8 October 2026 · Back to the help centre