Probe to Cremit Platform: what credential scanning does today
An updated guide to Cremit Platform’s scan sources, live credential checks, and remediation workflow, with current product limits.
On this page(4)
Updated October 3, 2026. This article originally introduced Probe, an earlier name used for Cremit’s credential detection work. The current product is Cremit Platform. The feature and benchmark claims in the original article no longer describe its verified scope.
What the platform scans
Cremit Platform looks for exposed credentials in connected code repositories, cloud storage, and collaboration tools. Supported sources include GitHub, GitLab, Bitbucket, GitHub Packages images, AWS S3, Google Drive, Jira, Confluence, Notion, and Slack. GitHub pull requests can be checked when they arrive through the GitHub App; other sources are scanned on a schedule.
A secret in a repository is only one part of the problem. A token can also land in a chat message, issue comment, document, or storage bucket. Connect the sources your team actually uses and review scan coverage for each one. The platform cannot find material in a source it cannot access.
Detection is different from verification
Detection rules cover more than 1,000 credential types. A pattern match is a lead, not proof that a key still works. For supported types, the platform checks the credential against its issuing service and rechecks live findings on a schedule. Other matches need manual review. Treat a confirmed live key as a rotation or revocation task at the issuing service; a dashboard status alone does not disable it.
The finding view records where a credential was found and gives the team a way to assign an owner, set its status and priority, and send alerts through configured Slack, webhook, Telegram, or email channels. These steps help a security team follow up, but the team remains responsible for revoking the credential and checking whether it was misused.
A first scan that produces useful work
Start with one repository and one collaboration source that regularly carries operational notes. Confirm that the connector has only the access it needs, then check a known test secret or an existing finding. Review whether the result identifies the source, verification state, owner, and next action. After rotating a live key, confirm the issuing service rejects it and the platform’s later check reflects the change.
The platform detects exposed credentials, API keys, and tokens. It does not classify general personal information or business documents. It also does not automatically rotate or revoke credentials. Those boundaries matter when you choose controls for privacy data and incident response.
Where to go next
See the current product and integration pages for supported sources, verification, and alerting. If you are assessing a specific connector or credential type, check its support before planning a rollout.
Read next
AWS S3 secret scanning: what a connected bucket shows
Cremit reads supported current objects in connected S3 buckets to locate credentials. Check access, skipped objects, earlier versions and the issuer separately.
From exposed credentials to Cremit Platform: the workflow we support
How Cremit Platform finds exposed credentials, verifies supported types, and routes findings to an owner, with clear limits.
Your Slack Webhook Is Write-Only, Until an AI Agent Reads the Channel
A leaked Slack incoming webhook is usually triaged as low severity: write-only, one channel, no data access. The moment an AI agent reads that channel and can act with tools, that write-only primitive becomes an indirect prompt injection path into the agent's privileges. Here is the full kill chain, the exact preconditions, and how to defend it.
Get the next one in your inbox
Monthly NHI security brief from Cremit. One email, high signal.