AI DLP secret validity checks: read the status

A secret-validity result needs its source, time and coverage limits. Ask whether the checker contacted the credential issuer, what it sent and how it records an inconclusive response. A credential can require investigation even when an online check returns an inactive status.

For AI data loss prevention, this is a buying question about any proposed credential-checking feature. GitHub's repository secret scanning provides a documented reference. Its documentation here concerns repository alerts; coverage of AI chat or agent traffic would need separate evidence from the relevant supplier.

Follow the check to the issuer

GitHub's validity-check guidance says it periodically sends a detected secret to its issuer and tests it against that service's APIs. Some checks include contextual information such as a host or URL.

GitHub says it typically uses GET requests and minimally intrusive endpoints. That qualified wording leaves the exact behaviour dependent on the credential type and issuer. The published description does not specify a universal checking interval.

Ask an AI DLP supplier to draw the corresponding data path. Does checking happen locally, in its service or through a third party? Which part of the detected value leaves the original environment, and can the organisation disable online validation while retaining local detection?

A design review should cover the check's logs as well as the request itself. Record whether hostnames, account identifiers or surrounding content are retained. Keep the data-handling decision with the feature configuration so a later upgrade receives the same review.

Preserve the meaning of unknown

GitHub's alert-evaluation documentation labels an unknown result as possibly active. It can mean the token type lacks a supported validity check or that GitHub could not verify the secret.

Those cases need distinguishable operational records. Unsupported coverage directs a team to another evidence source. A failed check may need investigation of service availability or permissions. Neither condition supplies a verified finding that the credential cannot be used.

For an inactive result, GitHub advises checking whether unauthorised access has already occurred. The present result and the exposure history answer different questions. Preserve the detected time, last checked time and issuer context when reviewing the incident.

Check the exact credential pattern

GitHub's supported-pattern table distinguishes detection, validity checks and other capabilities. Coverage varies within a provider's credential types, so a vendor name is too broad for an acceptance criterion.

The table accessed on 7 October 2026 lists validity checks for OpenAI API keys and Anthropic API keys. It lists no validity check for Azure OpenAI keys or Google Gemini API keys. GitHub also excludes generic patterns, such as private keys and connection strings, and AI-detected passwords from validity-check support.

Use a small coverage register with one row per credential type your organisation uses. Include detection support, online-check support, required configuration and the response to an unknown status. Confirm the current plan and repository prerequisites with the supplier because documentation and availability can change.

Keep status provenance with the alert

GitHub's secret-scanning REST API allows a validity override to be set or cleared. An exported status therefore needs provenance: identify whether it came from a provider check or a manual override, and who authorised any change.

The same API's alert-list parameters include hide_secret, which defaults to false. That is a practical warning for evidence exports. Select a content-minimised response where supported and verify the exported fields before sharing an incident pack.

This differs from exact data matching, which tests whether content matches a known organisational record. A format match, a validity result and an authorised disclosure each require their own interpretation.

Test the workflow without working credentials

Use mechanically non-functional synthetic canaries for detection and handling checks. Agree the expected provider-call behaviour before a controlled test. Avoid assuming that a fake token will produce a particular online validity status; the documentation does not establish that result.

For an active-secret path, request documented behaviour and safe vendor-provided evidence. Testing a real credential would introduce an exposure that a procurement exercise should avoid. Record any path that remains unverified.

GitHub's remediation guidance names the issuer as the most reliable source for credential validity and revocation as the central remediation step. Keep revocation and misuse investigation in the organisation's response procedure, with a named owner and an explicit deadline.

This guide describes documented GitHub behaviour and proposed buyer checks. We have not tested provider accounts or established that any particular AI DLP product performs online validity checks.

Map your sensitive-data controls with Promptective.