Notifications
Clear all
Topic starter
27/06/2026 1:50 pm
TL;DR: APIs now function as unmanaged identities in many enterprises, with static keys, shared secrets, and long-lived permissions creating a trust gap that human-focused IAM does not close, according to Abnormal AI. Treating API access as identity governance, not plumbing, is now a prerequisite for least privilege and Zero Trust consistency.
NHIMG editorial — based on content published by Abnormal AI: Key Insights APIs now represent unmanaged identities in most enterprises
Questions worth separating out
Q: How should security teams govern API access as a non-human identity?
A: Security teams should inventory APIs as identities, assign an accountable owner, and enforce lifecycle controls for issuance, rotation, expiry, and revocation.
Q: When does just-in-time access make more sense than standing API credentials?
A: JIT makes more sense when an API only needs access for a bounded workflow and the organisation can enforce temporary authorisation centrally.
Q: What do organisations get wrong about machine secrets in CI/CD pipelines?
A: The most common mistake is treating secrets as deployment convenience rather than identity risk.
Practitioner guidance
- Treat every API key as a governed identity Create an inventory of API keys, tokens, certificates, and service connections with an owner, purpose, expiry date, and revocation path.
- Replace standing machine privilege with task-scoped access Use temporary authorization patterns where the workflow allows it, so machine credentials are issued for a narrow purpose and revoked automatically after use.
- Move identity guardrails into CI/CD pipelines Add checks that block hardcoded secrets, unnamed service accounts, and overbroad permissions before deployment.
What's in the full article
Abnormal AI's full article covers the operational detail this post intentionally leaves for the source:
- The article’s full argument for why APIs should be managed as identities across authentication, authorization, and monitoring.
- The step-by-step case for just-in-time access as a machine privilege pattern rather than a human-centric control.
- The discussion of how CI/CD guardrails and cross-team collaboration change developer behaviour around API governance.
- The source’s specific framing for how CISOs can embed API identity into broader IAM policy and culture.
👉 Read Abnormal AI's analysis of API identity governance and just-in-time access →
API identities and JIT access: are your controls keeping up?
Explore further
27/06/2026 3:19 pm
API identity is now a primary governance surface, not a technical detail. The article’s core claim is correct in one important sense: APIs often carry more effective access than individual users, yet are still managed as interfaces rather than identities. That creates unmanaged trust relationships, especially where ownership, purpose, and revocation are missing. The governance conclusion is simple: if the identity is not named and lifecycle-managed, it is not truly governed.
A few things that frame the scale:
- From our research: 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
- That same research found 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent, which shows how machine access leaks now move through everyday workflow systems.
A question worth separating out:
Q: How can teams tell whether API identity governance is working?
A: A working programme can answer who owns each API, why it exists, when it expires, and how it is revoked. It also produces clear evidence that privileged access is temporary where possible and that abnormal behaviour is detectable in real time. If those questions are hard to answer, governance is still incomplete.
👉 Read our full editorial: Just-in-time identity for APIs is becoming an IAM control gap
