What Microsoft says it observed
Microsoft Threat Intelligence published its report on November 5, 2026. It says threat actors used an agentic framework to search public GitHub repositories for exposed credentials, including application secrets and AI inference keys, then analyze results and carry out follow-on activity. Microsoft describes at least one case in which an agent moved from repository scanning to data exfiltration from Azure Key Vault in five minutes. This is Microsoft’s incident reporting; the article does not independently verify the cases.
Microsoft also reports successful service-principal sign-ins beginning October 28 for some affected customers and describes cloud resource discovery and data access involving Key Vault and Storage. It says some compromised credentials originated in a vendor-owned multitenant application, which can create downstream exposure across customers. The report does not mean every public secret is automatically exploited, but it underscores why removing a string from a repository alone is not enough.
A detected secret must be treated as compromised
If a credential appears in public code, assume someone may have copied it even if the repository was quickly made private or the commit was rewritten. Revoke or disable the exposed credential first, then issue a replacement through the provider’s approved process. Update dependent services securely, confirm the old credential no longer works, and review logs for use outside expected times, locations, identities or resource patterns.
Identify what the credential could access and whether it was reused across environments. A leaked development key should not also authorize production. For a vendor or service principal, contact the provider and determine which customer tenants or applications share the identity. Preserve relevant audit evidence and involve the organization’s incident-response owner; do not rely on a clean-looking repository history as proof that exposure ended.
Reduce the chance of another exposure
Enable secret scanning and push protection on repositories where available, including public-repository monitoring when the organization’s plan supports it. Store credentials in a managed secret store, grant each identity only the permissions it needs, and prefer short-lived credentials or workload identity where practical. Separate production and test credentials, maintain an owner and expiry process, and alert on unusual authentication and sensitive data access.
Review automated jobs, forks, build logs, issue attachments and deployment configuration as well as the primary source branch. Secret scanning catches supported formats; it cannot prove that every credential type is absent. A periodic inventory and access review remain necessary, especially for vendor integrations and machine identities.
A response checklist for small teams
1) Revoke the exposed secret. 2) Rotate it and update the legitimate service through a trusted channel. 3) Check identity and cloud audit logs for use of the old secret and related accounts. 4) Limit or suspend suspicious access while preserving evidence. 5) Search owned repositories and build systems for copies. 6) Add scanning and push protection, then review least privilege and expiry.
If data or customer environments may have been accessed, follow the organization’s incident and notification process and consult qualified security support. Microsoft’s post includes technical detections and hunting material for defenders; this article intentionally stays at defensive response level. The principal operational lesson is that a secret is an identity: once exposed, rotate the identity and investigate what it could reach.
Sources & further reading
Have a factual correction or a source to suggest? Contact the editorial desk.
