Skip to main content
GitLab is a code-repository data source. Flint AI scans your repository’s source for AI agents and reports the models, tools, and MCP servers behind them, along with any security issues it finds. The scan runs as a GitLab CI/CD component inside your own pipeline, so there is no credential to store in Flint AI. You authenticate the component with a Flint AI API key. GitLab is a separate data source from GitHub so that results found on each are recorded and shown apart. Agents discovered on GitLab trace back to their GitLab repository. To open this page, go to Settings, then Data sources, select GitLab, and open the Setup tab.

​
Connect a repository

1

Get your credentials

You need two values: your Flint AI instance URL and a Flint AI API token.
  • Instance URL. The Setup tab shows the exact URL to use. Copy it from there.
  • API token. Use an existing token, or create one now if you don’t have one. Tokens are managed under Settings, then API Keys, and the Setup tab has a Create one now shortcut.
2

Install the GitLab CI/CD component

Install flintai-codescan-workflow from the GitLab CI/CD Catalog and include it in your project’s .gitlab-ci.yml:
Unlike GitHub Actions, a GitLab CI/CD component cannot read your CI/CD variables by itself. Pass $VARIABLE references explicitly in your .gitlab-ci.yml so GitLab expands them at runtime. Only the token needs to be masked. Your instance URL is not sensitive, so pass it to the component’s flintai_instance input as a plain value.
3

Store your token as a GitLab CI/CD variable

In your project or group settings, go to Settings, then CI/CD, then Variables, and add a variable named FLINTAI_TOKEN with the token from the first step. Enable the Mask variable toggle to keep it out of job logs.Scanning more than one repository? Define this variable at the group level so it is shared across projects.
4

Enable LLM-based scanning

The scanner calls an LLM from the pipeline to analyze your code, so this step is required.
  • Add your LLM provider’s API key as a masked CI/CD variable. Name it for your provider, one of OPENAI_API_KEY, GOOGLE_API_KEY, or ANTHROPIC_API_KEY, then reference that same variable through the llm_api_key input. The example above uses llm_api_key: $ANTHROPIC_API_KEY to match its anthropic model.
  • Choose the model with the llm_model input, in provider:model form.
Supported providers are OpenAI, Google (Gemini), and Anthropic.
Once the pipeline runs and reports its first scan, the GitLab card reads Connected.

​
Restrict to the default branch (optional)

Use the rules input to control when the scan runs, for example only on the default branch:

​
Target a specific runner (optional)

The component adds a scan job named flintai-inventory-scan. If a particular runner supports docker:dind, override that job with the appropriate tags:

​
The Scans tab

Open the Scans tab to see each connected repository with the time of its most recent scan. A fresh timestamp means results arrived.
Check the Scans tab, not the Connected status, to confirm results are landing. The card status does not yet reflect a live connection check, so it can read Connected before your first scan has run.

​
Next steps

Discover your agents

Set up a repository scan end to end, from workflow file to first results

Read your discovery results

Work out what needs attention first, whether a finding is real, and when it’s resolved