Notifications
Clear all
Topic starter
21/08/2026 4:44 pm
TL;DR: API keys still leak through repos, Slack, Jira, tickets, and AI prompts, and Strac’s guide argues that secure storage, rotation, monitoring, and least privilege are all needed to reduce exposure. The governance gap is that AI and MCP workflows can ingest secrets before traditional DLP or review processes ever see them.
NHIMG editorial — based on content published by Strac: The Comprehensive Guide to Sharing and Storing API Keys Securely
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: What breaks when AI agents rely on shared service accounts or API keys?
A: Shared credentials hide which actor actually performed the action, make revocation coarse, and blur accountability across humans and machines.
Q: Why do API keys create more risk than many teams expect?
A: API keys are persistent machine credentials, so they often outlive the task or system that created them.
Q: How do teams know if identity-aware secret scanning is actually working?
A: It is working when findings are routed to clear owners, live credentials are resolved quickly, and revocation or rotation happens without production instability.
Practitioner guidance
- Inventory every API key path Map where keys are created, stored, copied, transmitted, and reused across repos, chat, tickets, AI prompts, and third-party integrations.
- Extend secret scanning beyond source code Scan Slack, Jira, Google Workspace, GitHub, documents, screenshots, and prompt logs for API keys, tokens, private keys, and passwords.
- Shorten the credential lifecycle Rotate keys on a fixed schedule, delete obsolete credentials, and prefer service-specific keys over shared master keys.
What's in the full article
Strac's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step handling guidance for API keys in SaaS, cloud, and Gen AI workflows
- Detailed do and don't examples for storage, sharing, rotation, and recovery
- Implementation guidance for secret scanning, redaction, and access limits across collaboration tools
- Third-party integration controls, including contractual and audit requirements for shared keys
👉 Read Strac's guide to sharing and storing API keys securely →
API key leakage in AI workflows: are your controls keeping up?
Explore further
21/08/2026 5:04 pm
API key security is now a non-human identity governance issue, not just a developer hygiene issue. API keys function as machine credentials, so their custody, scope, and revocation need the same governance discipline applied to other NHI estates. The article usefully shows that leakage is not confined to code repositories; it now spans collaboration systems and AI-enabled workflows. Practitioners should manage API keys as identities with lifecycles, not as static text strings.
A few things that frame the scale:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as very concerned, according to The 2024 State of Secrets Management Survey.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
A question worth separating out:
Q: Who is accountable when a compromised API secret is reused across multiple systems?
A: Accountability usually sits across application owners, platform teams, and identity governance because the failure spans issuance, distribution, and revocation. Mature programmes assign a single owner per secret class, define who can rotate or retire it, and require evidence that downstream consumers were updated.
👉 Read our full editorial: API key leakage in AI workflows exposes a broader governance gap
