Agentic AI tooling: five minutes from a leaked GitHub secret to Key Vault - what CISOs should do
Agentic AI tooling is shortening the path from a leaked secret to a cloud breach. Keys and application credentials left in public GitHub repositories can be found, assessed and used with far less hands-on work from an attacker. Research published on 5 November by Microsoft Threat Intelligence described an AI agent moving from searching GitHub for secrets to accessing data in Azure Key Vault in five minutes.
For CISOs, the practical question is response speed: can the organisation contain an exposed application credential quickly enough? For Chief AI Officers responsible for AI services, it also asks whether anyone has a reliable account of the keys and application permissions supporting those services.
What the research found
That Threat Intelligence write-up describes threat actors using an agentic AI offensive framework, including ARTEX, to search public GitHub repositories for exposed credentials, application secrets and AI API keys. The tooling can analyse the results and carry out follow-on steps with less hands-on work from an operator.
The five-minute Key Vault case is one observed incident, not a claim that every attack follows that timetable. It shows how little time can separate discovery from data access when a usable credential sits in public code.
From as early as 28 October, the research recorded successful service principal sign-ins from 199.19.77.84 involving multiple application IDs. Service principals are application identities: their permissions determine what an authenticated application can reach. In some cases, a credential for a vendor-owned multitenant application had been compromised at source and used against downstream tenants.
Follow-on activity included cloud resource discovery, credential and data access from Key Vaults and Storage Accounts, and use of compromised credentials against Azure AI services. The same write-up covers SharePoint and OneDrive file downloads, mailbox-item access, Microsoft Graph searches and use of Run Command on Azure virtual machines through compromised OAuth applications. Taken together, that gives CISOs a concrete checklist of places to look once an application identity may be involved.
What changes when the tooling can adapt
Searching public repositories for secrets is not new. The difference with agentic AI tooling is the combination of discovery, analysis and action, with fewer pauses for human decisions.
The research described failed cloud API requests being retried with corrected API versions seconds later and then succeeding. A failed request was not necessarily the end of the attempt. For defenders, repeated failures followed by success deserve attention alongside outright successful access.
The agents also focused on credentials that opened AI services, including API keys and OAuth applications with access to Foundry Tools, previously known as Azure Cognitive Services. AI credentials therefore belong in the same access reviews and incident plans as other sensitive application credentials, not in a separate experimental category.
What CISOs should do this week
1. Treat an exposed credential as compromised
Scan public code for secrets and enable GitHub secret scanning and public monitoring where available. Public monitoring can help identify exposure beyond repositories the organisation owns. Review secret protection and push protection for Azure DevOps where available.
If a credential is exposed, revoke or rotate it immediately. Deleting the file or removing the commit does not invalidate the credential. Assign an owner to investigate its historical use and establish what the application could access.
2. Contain the application, then follow its permissions
For affected applications, the published guidance includes removing all client secrets, certificates and federated credentials, and disabling the service principal if needed. Already-issued tokens can remain valid until expiry, so removing a secret is not the whole response. Revoke affected user sessions and Azure DevOps personal access tokens where applicable.
Rotate the secrets stored in any Key Vault the affected application could read, not just the credential first discovered. Investigate accessed documents for further credentials that may also need replacing.
3. Hunt for behaviour as well as an address
Review service principal sign-ins for 199.19.77.84, including failures. Extend the investigation into Azure Activity, Key Vault and Storage logs, application changes and Microsoft 365 audit records.
Look for one IP authenticating to three or more service principals, or one application requesting access across several services in a short period. Do not let a clean result for one known address close the investigation: attackers can change their infrastructure.
The research recommends blocking 199.19.77.84/32 through Conditional Access for workload identities where licensed. These policies require Workload ID Premium and apply to single-tenant applications registered in the organisation's tenant, so teams should confirm that scope when they put the block in place.
4. Reduce what a stolen identity can reach
Review service principal permissions against the application's actual purpose. Remove unnecessary access to vaults, storage, AI services and administrative operations. Check that relevant Key Vault and workload monitoring is enabled and that alerts reach a team able to act.
Prefer managed identities over long-lived client secrets where supported. For credentials that remain necessary, record an accountable owner, purpose, permissions and rotation process. Include AI API keys in that inventory.
5. Check delegated access with providers
Ask relevant providers how they review application credentials and downstream access. Guidance for managed service providers in the same write-up includes reviewing Partner Center access, granular delegated admin privileges relationships and customer tenants, and notifying affected customers under their agreements. This is a review prompt drawn from the published research, not evidence that any particular provider has been affected.
Make ownership explicit
The leadership task is to know which non-human identities can reach sensitive data and AI services, who owns them and who can disable them. CISOs and CAIOs should agree those responsibilities before the next exposed key is found. A five-minute window from a public leak to cloud access is a reason to rehearse that decision in peacetime, rather than leave it to the incident itself.
Sources
Image: panumas nikhomkhai on Pexels (Pexels License).
