Topic starter
12/06/2026 9:53 pm
TL;DR: API traffic is expanding quickly, with 25% of businesses saying the number of APIs they manage doubled or more last year, while machine-accessed endpoints remain exposed to credential stuffing, scraping, and abuse according to Arkose Labs and Salt's State of API Security Report 2025. Browser-era controls do not translate cleanly to machine-to-machine traffic, so identity, rate, and risk controls must move to the edge.
Editorial analysis by NHI Mgmt Group, based on content published by Arkose Labs: “Protecting Programmatic API Endpoints Before It's Too Late”.
By the numbers:
- 25% of businesses reporting that the number of APIs they manage doubled or more last year.
Key questions
Q: What breaks when browser-based controls are used to protect machine-to-machine APIs?
A: Browser-based controls often fail because machine clients do not generate the same telemetry, user interaction, or client-side signals that those tools expect.
Q: Why do machine-to-machine APIs increase abuse risk in enterprise environments?
A: They increase risk because they expose high-value functions directly to automated clients, often with long-lived tokens or broad access scopes.
Q: What are the signs that API abuse controls are too weak for programmatic traffic?
A: Repeated authentication attempts, silent scraping, unexplained inventory depletion, and legitimate clients being throttled while abusive clients keep operating are strong warning signs.
Practitioner guidance
- Define machine-client trust separately from browser trust Inventory which APIs are consumed by software clients, then classify them as machine-to-machine paths with their own authentication, risk, and abuse controls.
- Push enforcement to the API edge Apply authentication, throttling, and contextual request inspection at ingress so suspicious automation is stopped before it reaches backend systems and data stores.
- Tune controls for continuous abuse patterns Look for credential stuffing, scraping, and inventory manipulation that can operate at low and persistent rates, then set detection logic to catch sustained patterns rather than only bursts.
Bottom line: Machine-to-machine API traffic requires a different security model because browser-centric controls do not reliably identify or stop automated callers.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
13/06/2026 12:17 am
Machine-to-machine API security fails when teams inherit browser-era trust assumptions. The article shows that programmatic traffic needs a different control model because client-side checks do not exist in the machine channel. That means the core governance problem is not simply API growth, but the absence of controls that are built for non-browser identity and request behaviour. Practitioners should treat machine access as a separate governance domain, not a browser variant.
A few things that frame the scale:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: How should security teams govern machine identities differently from human users?
A: Security teams should govern machine identities with lifecycle, context, and runtime controls, not human approval workflows. That means separate ownership, purpose-based entitlement, expiry, and revocation for service accounts, bots, and agents. Human IAM can inform the model, but machine access needs faster review, tighter scoping, and automated enforcement.
👉 Read our full editorial: Machine-to-machine API security is lagging behind enterprise growth