Microservices security gaps are exposing API sprawl and shadow APIs

At a glance

What this is: This is Kong's analysis of how microservices create API security and governance gaps, with shadow APIs, internal trust failures, and secrets mismanagement as the main risks.

Why it matters: It matters because distributed applications expand identity and access control requirements across service accounts, tokens, secrets, and machine-to-machine paths that existing IAM models often under-cover.

By the numbers:

• API calls make up a massive 71% of all web traffic, yet many organizations still rely on traditional security tools designed for monolithic architectures.
• Machine learning discovered 30.7% more API endpoints than self-reported approaches, suggesting nearly a third are shadow APIs.
• Attacks targeting the business logic of APIs constituted 27% of attacks in 2023, a 10% growth since the previous year.

👉 Read Kong's analysis of 10 microservices security challenges

Context

Microservices change the security problem by multiplying identities, endpoints, and trust relationships. Instead of one application boundary, teams inherit dozens or hundreds of service-specific access paths that must be authenticated, authorised, observed, and governed as a single programme.

For IAM, NHI, and platform teams, the core issue is not just exposure. It is the mismatch between distributed execution and controls that were designed for coarse-grained perimeter security, static secrets, and infrequent change. Kong's article frames that mismatch through APIs, service-to-service traffic, and configuration drift.

The strongest takeaway is that microservices security is an identity governance problem as much as an application security problem. That makes service accounts, token validation, secrets management, and internal policy enforcement first-class controls rather than implementation details.

Key questions

Q: How should security teams govern APIs in microservices environments?

A: Security teams should govern APIs as a continuously changing identity surface, not as a fixed application perimeter. That means automated discovery, ownership tagging, policy enforcement, authentication at every hop, and regular review of undocumented routes. Without those controls, endpoint growth outpaces governance and shadow APIs become the easiest place for attackers to hide.

Q: Why do microservices increase lateral movement risk?

A: Microservices increase lateral movement risk because one service compromise can expose internal trust relationships, shared secrets, and downstream permissions. If internal calls are broadly trusted, the attacker does not need to break many systems. They only need one weakly governed service to inherit access across the cluster.

Q: What do teams get wrong about Kubernetes Secrets?

A: Teams often treat Kubernetes Secrets as if they are secure by default, but base64 encoding is not encryption and cluster access can expose them. The bigger issue is lifecycle control. Secrets need ownership, rotation, revocation, and monitoring, or they become standing credentials spread across many services.

Q: How do organisations know if their microservices controls are working?

A: The clearest signal is whether every active endpoint is inventoried, every internal call is authenticated, and every credential has a known owner and rotation path. If teams cannot answer those three questions quickly, governance is incomplete and the environment contains unmanaged exposure.

Technical breakdown

API sprawl and shadow endpoints

Microservices split a single workload into many small services, and each service exposes its own routes, methods, and data paths. That creates API sprawl, where the true inventory of endpoints quickly diverges from what teams think they run. Shadow APIs are the dangerous edge case: endpoints that reach production without security review, ownership metadata, or monitoring. In distributed systems, discovery has to be continuous because change is constant and internal visibility is fragmented.

Practical implication: maintain automated API discovery, ownership tagging, and inventory audits so undocumented endpoints are found before attackers do.

East-west trust and service-to-service authentication

In microservices, authentication happens at the edge and again between services. If internal calls are trusted by default, one compromised service can inherit access to downstream data and functions. This is where Zero Trust Architecture becomes more than a slogan: each request needs independent verification, and each service should enforce policy rather than assuming anything inside the cluster is safe. mTLS, service identity, and centralised policy enforcement reduce the blast radius of a single failure.

Practical implication: eliminate implicit internal trust and require explicit authentication and authorisation for every service-to-service call.

Secrets, configuration drift, and control-plane sprawl

Every microservice often carries its own secrets, certificates, and environment-specific configuration. That increases the number of places where credentials can be exposed, copied, or left stale. Kubernetes Secrets and similar stores do not solve the problem by themselves if the surrounding lifecycle is weak. The real challenge is governance over provisioning, rotation, and offboarding across many services and environments. Without automation, configuration drift turns into a standing access problem.

Practical implication: centralise secrets management, automate rotation, and tie configuration changes to identity lifecycle controls.

Threat narrative

Attacker objective: The objective is to turn one weakly governed service path into broad access across data, logic, and backend systems.

1. entry: Attackers often start through an exposed or undocumented API endpoint, or by compromising a microservice that already has network reach inside the cluster.
2. escalation: They abuse weak internal trust, stale secrets, or permissive service-to-service policies to move from one service context into another.
3. impact: The attacker reaches sensitive data, business logic, or infrastructure resources at scale because the application is distributed but the governance model is still coarse-grained.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Microservices security is an identity governance problem before it is a tooling problem. The article correctly shows that endpoint growth, internal trust, and secrets sprawl all expand faster than manual controls can track. That means the real failure mode is not just exposure, but the absence of a governance model that can keep pace with distributed execution. Practitioners should treat microservices as a lifecycle and access-control challenge, not only an infrastructure pattern.

Identity blast radius: once service-to-service trust is implicit, one compromised workload can inherit the authority of many. Kong's examples show why east-west traffic is the real control boundary in microservices, not the perimeter. When internal requests are trusted by default, the compromise of one service becomes a path into data stores, payment flows, and administrative functions. Practitioners should design for bounded trust, because broad internal reach is what turns small failures into enterprise incidents.

Secrets sprawl creates standing privilege by another name. When every service carries its own credentials, certificates, and configuration, the security model becomes dependent on perfect hygiene across hundreds of identity artifacts. That assumption rarely holds in practice, which is why stale keys, copied tokens, and misconfigured stores keep reappearing as the first usable foothold. Practitioners should govern secrets as identities with lifecycle, ownership, and revocation requirements.

Shadow APIs are governance failures, not just discovery gaps. The fact that machine learning found 30.7% more endpoints than self-reported approaches tells you that inventory processes are already behind reality. A control that cannot see the full estate cannot enforce scope, classify data exposure, or support incident response. Practitioners should treat undiscovered APIs as unmanaged identity surfaces until proven otherwise.

The security programme must shift from static control sets to continuous assurance. Microservices change too quickly for periodic review alone to be sufficient. The article points toward an operating model built on discovery, policy enforcement, and runtime visibility, because that is what the environment now demands. Practitioners should align identity, secrets, and observability controls under one distributed governance plan.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• Forward view: Read NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding discipline that limits credential sprawl.

What this signals

Shadow API discovery is becoming a baseline governance requirement. If machine-driven discovery finds materially more endpoints than teams report themselves, then manual inventory is no longer a defensible control. Practitioners should expect discovery tooling, ownership metadata, and policy enforcement to become part of the core API governance stack rather than optional hardening. For a broader view of distributed identity controls, see the Ultimate Guide to NHIs , Key Challenges and Risks.

API security is converging with NHI lifecycle management. The more services, keys, tokens, and certificates a platform accumulates, the more the programme depends on lifecycle discipline instead of one-time configuration. When secrets are not tied to clear ownership and revocation paths, the organisation is carrying hidden identity debt that will surface during change, incident response, or audit.

Distributed systems will force closer alignment between architecture and governance. Microservices are not just a scaling pattern. They create a governance surface where identity, observability, and policy must operate together. Teams that separate those functions will keep discovering that the environment changes faster than their review cadence.

For practitioners

• Build a continuous API inventory Automate endpoint discovery across all environments and tag each route with ownership, data sensitivity, and business criticality so shadow APIs can be removed or governed quickly.
• Enforce explicit east-west authentication Require mTLS and service identity validation for every internal call, and block any default trust between workloads in the same cluster or namespace.
• Centralise secrets lifecycle control Move service credentials, API keys, and certificates into a managed lifecycle with rotation, revocation, and audit logging tied to service ownership.
• Use policy as code for authorisation Define service permissions in code, test them in CI, and reject deployments that introduce broad internal access or unauthorised service paths.
• Instrument distributed tracing for governance Correlate requests across services with trace IDs so security teams can see unusual internal paths, unexpected service relationships, and lateral movement patterns.

Key takeaways

• Microservices security fails when teams treat distributed identities like a monolith.
• Endpoint sprawl, internal trust, and secrets drift combine to create shadow exposure that traditional tools miss.
• Continuous discovery, explicit service authentication, and governed secrets lifecycle are the controls that change the risk profile.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• East-west traffic: Internal service-to-service communication inside an application or cluster. Unlike north-south traffic, which crosses the external boundary, east-west traffic often bypasses traditional perimeter tools, so it needs its own authentication, authorisation, encryption, and monitoring controls.
• Service identity: The identity a workload uses when it calls another service or resource. In microservices, service identity is often represented by tokens, certificates, or workload credentials, and it becomes the basis for trust, policy enforcement, and accountability across the environment.
• Secrets lifecycle: The managed process for issuing, storing, rotating, revoking, and auditing credentials such as API keys, tokens, and certificates. In microservices, lifecycle control is critical because each service may own multiple secrets across several environments, making stale access easy to miss.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 Kong: 10 Ways Microservices Create New Security Challenges. Read the original.