API security examples show why cryptographic identity matters

At a glance

What this is: This is a thought leadership piece on API security examples, showing how weak client authentication, static keys, and missing controls lead to large-scale data exposure.

Why it matters: It matters because API security now intersects directly with NHI governance, service identity trust, and access control decisions across partner ecosystems and machine-to-machine programmes.

By the numbers:

• 84% of surveyed organizations are exposing sensitive data via weak API security practices.
• 49 million records leaked during the Dell API breach after an attacker used a public endpoint and a service tag.

👉 Read Raidiam's API security examples and breach analysis

Context

API security is the discipline of controlling how services authenticate, authorise, and monitor machine-to-machine requests. In this article, the main failure pattern is not a single broken endpoint but weak identity controls around APIs, especially where clients are trusted too broadly or for too long.

That matters for NHI governance because API keys, client secrets, certificates, and access tokens are all non-human identities in practice. When scope, expiry, binding, and monitoring are weak, the attack surface shifts from application logic to identity lifecycle and runtime authorisation.

The article also shows the gap between generic API hardening advice and cryptographic identity models such as mTLS and FAPI. The starting point is typical of many enterprise environments: fast API growth, uneven controls, and too much reliance on bearer-style trust.

Key questions

Q: How should security teams secure APIs that rely on machine-to-machine credentials?

A: Security teams should replace reusable shared secrets with short-lived, scoped credentials and bind them to a verified client identity. mTLS and private_key_jwt are stronger because they reduce replay risk and tie access to the connecting workload or partner. The goal is to make stolen credentials much less useful.

Q: Why do static API keys create such a large security risk?

A: Static API keys are risky because they behave like bearer tokens. If they are embedded in code, copied into multiple systems, or never expire, anyone who finds them can use them until they are rotated. That creates long-lived standing access and makes exposure hard to contain.

Q: What do teams get wrong about API rate limiting and monitoring?

A: Teams often treat rate limiting as a performance setting instead of an identity control. In practice, it is one of the few ways to stop valid credentials from being used for scraping, enumeration, or brute-force abuse. Monitoring should look at client identity, request volume, and query shape together.

Q: Who is accountable when a partner API exposes customer data?

A: Accountability sits with both the API owner and the team governing the credential lifecycle. If third-party access is not scoped, monitored, and revoked when no longer needed, the organisation has accepted standing trust without lifecycle control. Frameworks such as NIST CSF and zero trust place that responsibility on access governance.

Technical breakdown

Static API keys and bearer-style trust

Static API keys behave like reusable bearer credentials. Whoever holds the key can use it, so the real control boundary becomes storage, exposure, and revocation rather than user intent. If the key is embedded in code, shared across apps, or never expires, the compromise window stays open until someone discovers and replaces it. That is why static secrets are structurally weak for APIs with broad reach or partner access. Practical implication: move sensitive API consumers to short-lived, scoped credentials and treat every exposed key as an incident.

Practical implication: replace long-lived API keys with scoped, short-lived credentials and treat exposure as an incident.

mTLS, private_key_jwt, and certificate-bound tokens

Mutual TLS and private_key_jwt replace shared-secret trust with cryptographic proof of client identity. mTLS requires the client to present a certificate during the connection, while private_key_jwt signs the authentication request with a private key the server can verify. Certificate-bound access tokens extend that model so stolen tokens are not reusable from another device or process. This matters because replay and interception are common failure modes in API ecosystems. Practical implication: bind token use to the authenticated client, not just to possession of a string.

Practical implication: bind token use to the authenticated client so intercepted credentials are not reusable elsewhere.

Rate limiting, anomaly monitoring, and API abuse detection

Rate limiting constrains how often a client can call an API, while anomaly monitoring looks for patterns such as scraping, brute force, or unexpected query volume. Without these controls, even a valid credential can be turned into a data-extraction tool. In the Dell breach example, automated scripts and weak endpoint controls allowed large-scale collection to continue undetected. The technical issue is not only access, but abuse at machine speed. Practical implication: monitor request behaviour as an identity signal, not just as traffic volume.

Practical implication: monitor request behaviour as an identity signal and stop abuse patterns before they become exfiltration.

Threat narrative

Attacker objective: The attacker’s objective was to harvest customer records at scale through a weakly protected API channel.

1. Entry occurred when an attacker posed as a fake partner and reached a public API endpoint using only a service tag as the lookup key.
2. Escalation followed because the endpoint lacked input validation, rate limiting, and behavioural monitoring, so automated scripts could enumerate records at scale.
3. Impact was the exposure of 49 million customer records, with the activity remaining undetected for weeks.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API security is now an identity governance problem, not just an application hardening problem. The article’s examples all fail at the point where a client identity is trusted too broadly, too long, or without binding to the runtime session. That puts API keys, tokens, and certificates squarely into NHI governance, because they are the identities that actually transact with services. Practitioners should manage APIs as governed identities with lifecycle, scope, and revocation discipline.

Static API keys create credential persistence that outlives operational intent. A hardcoded key in code or a shared secret in a client build is not simply weak authentication, it is standing privilege in disguise. Once exposed, the control problem becomes how quickly the key can be found, rotated, and invalidated across every consuming system. Practitioners should treat persistence of reusable API credentials as a blast-radius issue.

Cryptographic identity is the right model when partner access must be machine-verifiable. mTLS and private_key_jwt shift trust from possession of a shared secret to proof of control over a private key and certificate. That makes replay harder and gives security teams a stronger basis for zero trust between services. Practitioners should favour certificate-bound and short-lived credentials where API relationships carry material data exposure risk.

API abuse detection must be treated as identity telemetry. When a valid credential is used to scrape, enumerate, or query at machine speed, the key problem is no longer authentication success but behavioural misuse. The Dell example shows that automation plus weak control planes can leak millions of records without triggering obvious alarms. Practitioners should connect API rate limits, anomaly signals, and identity context in one control loop.

Fine-grained authorisation only works when entitlement scope matches the actual transaction model. The article repeatedly shows that broad permissions, missing expiry, and weak token binding turn a single exposed credential into multi-account or multi-record exposure. That is the same failure pattern identity teams see when RBAC is too coarse for partner APIs. Practitioners should align entitlement scope to the smallest viable API transaction.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many teams still cannot see where machine trust is concentrated.
• For a broader lifecycle view, Ultimate Guide to NHIs , Why NHI Security Matters Now shows why visibility, rotation, and offboarding need to be managed together.

What this signals

Identity blast radius: API security programmes increasingly need to measure how far a single credential can travel across partner systems, not just whether authentication succeeds. When 97% of NHIs carry excessive privileges, per Ultimate Guide to NHIs, the real risk is scope mismatch between what an API key can do and what the business intended.

Teams should expect more pressure to move from bearer-style trust to cryptographic identity, especially in regulated ecosystems where mTLS and signed client assertions are already becoming baseline expectations. The practical shift is toward stronger client binding, narrower scopes, and faster revocation when integrations change.

API monitoring needs to be treated as governance data. If request patterns, certificate status, and entitlement scope are not reviewed together, a valid credential can behave like an exfiltration tool without ever triggering a traditional authentication alert.

For practitioners

• Replace static API keys with scoped credentials Use short-lived credentials or certificate-bound tokens for API consumers that handle sensitive data. Remove hardcoded keys from code, rotate any shared secrets found in repositories or mobile builds, and revoke credentials that cannot be tightly scoped.
• Bind client identity to the transport session Use mTLS or private_key_jwt so the API server can verify the client’s cryptographic identity before issuing access. Prefer certificate-bound access tokens for partners or workloads that could otherwise replay bearer tokens from another environment.
• Instrument API abuse detection as an identity control Set rate limits, alert on unusual query volume, and correlate request patterns with client identity and entitlement scope. If a credential starts enumerating records or probing endpoints at machine speed, treat it as a misuse event, not normal traffic.
• Review third-party API trust relationships continuously Revalidate partner credentials, certificate status, and scopes on a recurring basis, especially where APIs expose customer records or financial data. Pair this with offboarding checks so unused integrations do not retain access beyond the business relationship.

Key takeaways

• Weak API security becomes an identity problem as soon as reusable credentials, broad scopes, and missing revocation controls are allowed to persist.
• The scale of API abuse is already material, with one breach leaking 49 million records and many organisations still lacking full visibility into the credentials they expose.
• Teams that want to reduce API risk should prioritise cryptographic client identity, short-lived access, and behavioural controls over static secrets and coarse permissions.

Key terms

• Mutual TLS: Mutual TLS is a connection method where both client and server present certificates and verify each other before data is exchanged. For API security, it binds access to a cryptographic identity rather than a reusable bearer secret, which makes interception and replay much harder.
• Certificate-bound access token: A certificate-bound access token is an access token tied to the client certificate used during authentication. If the token is stolen, it cannot be reused from another device or session without the matching certificate, which sharply reduces the value of token theft in API environments.
• Standing privilege: Standing privilege is access that remains continuously available rather than being granted only when needed. In API and machine identity contexts, it often appears as long-lived keys, broad scopes, or credentials that are rarely revoked, creating a larger window for abuse and data exposure.
• API abuse detection: API abuse detection is the practice of identifying misuse patterns such as scraping, enumeration, brute force, or automated record harvesting. It combines request behaviour, identity context, and volume signals so teams can distinguish legitimate machine traffic from activity that is technically authenticated but operationally suspicious.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Raidiam: API Security Examples: Learn From Breaches & Best Practices Thought Leadership. Read the original.