Scanning before a commit and triaging what already leaked are the same conversation here, with occurrences pinned to file and line so remediation is not a hunt. The permission model is the thing to set deliberately: the scopes on the token decide which tools appear at all, so a read-only token gives an agent that can investigate and not act.
GitGuardian's own server for secret detection and incident work. What your agent can actually do is decided by the OAuth scopes on the token, and it leans read-only by default.
- Files scanned for leaked credentials before they reach a commit, against GitGuardian's detector catalogue
- Incidents listed and filtered by severity, status and detector, with full detail and occurrences for any one of them
- Occurrences located precisely — the repository, the file path and the line number where the secret sits
- Step-by-step remediation instructions for a detected secret
- Source discovery: the repositories and integrations your workspace monitors, and auto-detection of the source id for the repository you are currently in
- The detector catalogue browsable, so you can see what is and is not being looked for
- Honeytokens created with placement recommendations, and existing ones listed
- Workspace members looked up when an incident needs an owner
A GitGuardian account. The recommended path is the hosted server — https://mcp.gitguardian.com/mcp for US, https://mcp.eu1.gitguardian.com/mcp for EU — where the client handles OAuth and there is nothing to install; requests then transit mcp.gitguardian.com as well as api.gitguardian.com. Self-hosted GitGuardian and airgapped setups run the server themselves, and CI or older clients use local stdio from PyPI as ggmcp with GITGUARDIAN_PERSONAL_ACCESS_TOKEN. GITGUARDIAN_URL points at a non-US instance. Browser-driven OAuth in stdio mode is deprecated; new stdio deployments should use a personal access token.