GitHub expands secret scanning with Resend tokens and monitoring insights

GitHub is adding more coverage and better triage data to secret scanning, with new detectors for APIclub and Resend, default push protection for VolcEngine Ark API keys, and richer public monitoring views for enterprises. The July 15 changelog also adds a secret_category field to secret scanning webhooks, giving security automation a cleaner way to separate provider-specific detections from generic or AI-detected secrets.

This is not a flashy product launch. It is the kind of platform security update that changes how quickly teams can catch leaked credentials, route alerts, and decide which exposures need action first.

GitHub now reports Resend tokens through its partner program

Resend is now part of GitHub's secret scanning partnership program. When GitHub finds exposed Resend tokens in public repositories, it can forward those findings to Resend so the issuer can revoke the credential or notify the relevant admins.

GitHub also added detectors for apiclub_api_key and resend_api_key. The distinction matters: partner secrets found in public repositories can be reported to the issuer, while user secrets generate alerts for repositories where secret scanning is enabled.

For teams using Resend in production apps, the immediate check is simple. Confirm that exposed keys are covered in GitHub alerts, rotate any historical tokens that may have appeared in public commits, and make sure webhook-driven workflows do not assume every secret type belongs to the same response path.

VolcEngine Ark keys now get default push protection

GitHub says volcengine_ark_api_key is now included in push protection by default. Repositories with secret scanning enabled, including free public repositories, will automatically block commits containing that detector.

That is a useful default for teams experimenting with AI APIs and regional model providers. Developer machines and test projects often accumulate temporary keys, and those keys can become long-lived by accident. Blocking the commit before it lands is cheaper than revoking a key after it is indexed, copied, or abused.

The practical caveat is coverage. Push protection only helps when the repository and workflow are actually covered by GitHub's scanners. Secrets can still leak through screenshots, issues, chat tools, build logs, local config files, and repositories hosted outside GitHub.

Webhooks can route generic and provider-specific secrets differently

The new secret_category field in the secret_scanning_alert webhook separates default detections from generic detections. GitHub defines default results as provider patterns plus custom patterns, while generic results include broader generic patterns and AI-detected secrets.

That small payload change can reduce noisy downstream logic. A security team can route high-confidence provider tokens to revocation workflows, send generic detections to human review, and report the two categories separately without maintaining a local map of detector names.

GitHub is also adding public monitoring insight cards that show associated leaks by attribution, enterprise member count, and verified domains. For enterprise responders, that turns the public monitoring list into a first-pass exposure dashboard instead of just another alert queue.

The broader credential problem is accelerating

GitHub's update lands against a larger secrets-sprawl problem. GitGuardian's 2026 report says 29 million new secrets were detected in public GitHub commits in 2025, with AI-service credential leaks growing sharply as AI-assisted development spread through software teams.

The operational lesson is direct: scanning is no longer just a repository hygiene control. Teams need prevention at commit time, alert routing that understands secret type and business impact, and public-surface monitoring for credentials leaked outside the repositories they own.

This GitHub update helps on all three fronts, but it does not replace key rotation discipline, short-lived credentials, least-privilege scopes, and inventory of non-human identities. The next useful audit is to check which secret types your organization actually uses, whether GitHub detects them, and whether your response automation treats generic findings differently from revocable provider tokens.