Traditional pentesting methodology was designed for a different era. The PTES (Penetration Testing Execution Standard) and OWASP Testing Guide were written when most applications were monoliths: one codebase, one deployment, one network boundary, one set of authentication controls. The pentest scope was clear: test the application from the outside, find ways in, document what you found.
Microservices shatter that model. A modern SaaS application might run 50–500 microservices, each with its own codebase, database, API, authentication mechanism (or none), and deployment lifecycle. The “application” isn’t a single target. It’s a distributed system where the interesting vulnerabilities live in the gaps between services, not within any single one.
When you hire a penetration testing firm to test a microservices application, here’s what typically happens. The firm receives a scope document listing the public-facing URLs. They spend Week 1 on reconnaissance and understanding the application from the outside. They test the API gateway, the web frontend, the mobile API endpoints. They find some issues (maybe an IDOR, a few missing headers, an outdated dependency). Week 2, they write the report.
What they don’t test: the 180 internal services communicating over gRPC behind the gateway. The message queue that passes unauthenticated JSON between services. The internal admin API that bypasses the gateway entirely. The service-to-service JWTs that never expire. The Kubernetes RBAC misconfiguration that lets any pod read secrets from any namespace.
That’s not the pentester’s fault. They were scoped for a two-week engagement against the public surface. The microservices interior is invisible from outside. Testing it requires inside access, architectural knowledge, and enough time to map and test hundreds of internal endpoints.
The attack surface in microservices extends far beyond what’s visible from the internet. Think of it as three concentric rings.
Ring 1: The perimeter (North-South traffic). This is what traditional pentests cover: the API gateway, load balancer, CDN, public-facing web and mobile endpoints. These are typically the most hardened because they’ve been pentested before, they’re behind a WAF, and the security team knows they’re exposed.
Ring 2: Inter-service communication (East-West traffic). This is where most microservices vulnerabilities hide. Services talk to each other over internal networks using REST, gRPC, GraphQL, message queues (Kafka, RabbitMQ, SQS), or event buses. This traffic is often unencrypted, unauthenticated, or authenticated with shared secrets that never rotate. A compromised or malicious service can reach every other service on the internal network.
In our experience testing microservices environments, East-West traffic vulnerabilities outnumber perimeter vulnerabilities by roughly 4:1. The reason is simple: teams invest heavily in perimeter security (WAFs, DDoS protection, rate limiting, authentication at the gateway) and invest almost nothing in internal service security. The assumption is “if it’s internal, it’s trusted.” That assumption fails the moment an attacker gets past the perimeter, or when an insider threat materializes, a dependency gets compromised, or SSRF lets an external attacker reach internal services.
Ring 3: Infrastructure and orchestration. Kubernetes API servers, container registries, CI/CD pipelines, secrets management, service mesh control planes, cloud IAM policies. These are the foundation that microservices run on. A misconfigured Kubernetes RBAC policy can give a single compromised pod access to every secret in the cluster. A container image with an embedded API key gives any developer who pulls it access to production databases.
Traditional pentesting focuses almost entirely on Ring 1. A thorough microservices pentest must cover all three, and Ring 2 is typically where the highest-impact findings live.
Some vulnerability classes either don’t exist in monolithic applications or become dramatically more dangerous in microservices architectures.
Broken inter-service authentication. In a monolith, internal function calls don’t need authentication because they’re in-process. When those functions become separate services, the communication channel needs authentication. Teams often skip this during the migration from monolith to microservices, or implement it weakly. We regularly find internal APIs that accept any request from the internal network without verifying the caller’s identity. An attacker who compromises one service gets unauthenticated access to every internal API.
Trust boundary confusion. Architecture diagrams show trust boundaries between services. Reality often disagrees. Service A is supposed to only talk to Service B, but the network policy permits Service A to reach Service C, D, and E as well. Kubernetes NetworkPolicies default to allow-all. Service mesh policies default to permissive mode. Unless someone explicitly locked down inter-service communication, it’s probably wide open.
Distributed authorization failures. Authorization logic gets duplicated, fragmented, or lost when a monolith is decomposed. The user service validates that User A has admin privileges. The billing service doesn’t check; it trusts whatever the user service says. But what if an attacker calls the billing service directly, bypassing the user service? In a monolith, that call path doesn’t exist. In microservices, it might.
Cascading failures from a single compromise. Compromise one microservice and you potentially reach all its dependencies. If the compromised service has database credentials, message queue access, and internal API tokens, the blast radius extends across the entire architecture. Traditional pentesting measures the impact of a single vulnerability. In microservices, the impact is a function of the service’s connectivity, and that’s rarely assessed.
Secrets sprawl. Each microservice needs credentials: database connections, API keys for dependent services, cloud provider credentials, TLS certificates. A 200-service environment might have 500+ secrets. They end up in environment variables, config files, container images, and CI/CD pipeline definitions. Tracking and rotating them all is a genuine operational challenge. Finding them during a pentest (in Kubernetes secrets, Docker layers, and Git history) reveals just how widely credentials are scattered.
Sidecar and service mesh bypasses. Service meshes like Istio and Linkerd enforce mTLS and authorization policies through sidecar proxies. But if a service communicates on localhost (bypassing the sidecar), or if the mesh is running in permissive mode, or if the authorization policy has wildcard rules, the security guarantees disappear. Testing whether the mesh actually enforces what it’s configured to enforce requires internal access and systematic validation.
Your Microservices Have 6 Vulnerability Classes That Monoliths Don’t
Broken inter-service auth, trust boundary confusion, distributed authorization failures, secrets sprawl — these risks multiply with every new service you deploy. Test your microservices environment with free AI pentest credits.
This isn’t a criticism of pentesters. It’s a structural problem with how microservices pentests are scoped and sold.
Scoping defaults to the perimeter. When a security team requests a pentest proposal, the natural scope description is “test our application at app.company.com.” The pentesting firm receives a URL, a set of credentials, and maybe an API spec. The scope is the external surface. Internal services aren’t mentioned because the security team may not even have a complete inventory of what’s running internally.
Access is limited. External pentesters don’t have network access to your internal Kubernetes cluster. They can’t reach the gRPC services running behind the API gateway. They can’t inspect message queue traffic. Testing East-West communication requires VPN access, a jump box, or a deployed agent, and most engagement contracts don’t include that level of access.
Time constraints kill depth. A two-week engagement leaves maybe 6–7 productive testing days after setup, scoping calls, and report writing. A complex microservices architecture takes 2–3 days just to understand: mapping services, dependencies, communication patterns, and authentication flows. That leaves 3–4 days for actual testing. The tester focuses where they can get the most findings in the least time: the API gateway.
The industry hasn’t adapted. were built for monoliths. OWASP Testing Guide has excellent coverage for web application vulnerabilities but limited guidance on inter-service security, service mesh testing, or container orchestration security. Pentesters use the tools and checklists available to them, and those tools are oriented toward perimeter testing.
The result: your pentest report covers the front door thoroughly and says almost nothing about the 95% of your architecture that lives behind it. And that report goes to your CISO, your auditor, and your board as evidence that the application has been “pentested.”
Effective microservices pentesting requires testing from three positions simultaneously: outside-in, inside-out, and service-to-service.
Outside-in testing is what traditional pentests do: testing from the internet through the API gateway. This covers perimeter defenses, authentication flows, and anything reachable from an external attacker’s position. It’s necessary but insufficient.
Inside-out testing places the tester (or agent) inside the cluster with the privileges of a typical microservice. From this position, you test what a compromised service can reach: internal APIs, databases, secrets, message queues, and other services. This reveals the blast radius of a single service compromise and identifies missing network segmentation, weak internal authentication, and over-permissioned service accounts.
Service-to-service testing validates that trust boundaries actually work. Can Service A (the user service) call Service C (the billing service) directly? Does the service mesh enforce authorization policies? Are mTLS certificates validated correctly? Can a service read Kubernetes secrets from other namespaces?
Here’s a practical framework:
Step 1: Map the architecture. Before testing anything, build a complete service inventory. Pull it from Kubernetes API, cloud provider metadata, service mesh configuration, API gateway routes, and CI/CD deployment manifests. You need to know every service, its dependencies, its exposed ports, and its authentication mechanisms.
Step 2: Identify trust boundaries. Where does the architecture assume one service trusts another? Where does authentication happen? Where does authorization get enforced? Map the intended trust model, then test whether reality matches.
Step 3: Test from inside the cluster. Deploy a testing agent or connect through Agent Shell inside the environment. Enumerate internal services from the perspective of a compromised pod. Attempt to access internal APIs without credentials, read secrets from other namespaces, escalate Kubernetes RBAC privileges, and reach services that should be unreachable.
Step 4: Test inter-service authentication and authorization. For every internal API, verify that it validates the caller’s identity and enforces authorization. Craft requests from unauthorized services. Replay tokens from one service to another. Test whether expired tokens are rejected.
Step 5: Test container and orchestration security. Check container images for embedded secrets (scanning Docker layers), Kubernetes RBAC for over-permissioned service accounts, pod security standards for privilege escalation paths, and CI/CD pipelines for credential exposure.
This five-step approach is thorough — and completely impractical for a manual pentest team to execute in a standard engagement. A 200-service environment following this framework would need 6–8 weeks of dedicated manual testing. That’s why AI-driven testing is the only way to get this coverage at realistic cost and cadence.
AI pentesting agents change the microservices testing equation by doing what human testers can’t: systematically testing hundreds of internal services in hours while maintaining the contextual understanding needed to identify meaningful vulnerabilities.
Here’s how it works in practice.
Automated service discovery. The AI agent queries Kubernetes API, cloud metadata services, DNS records, service mesh registries, and API gateway configurations to build a complete service map. It identifies every running service, its exposed ports, communication protocols, and dependency relationships. A task that takes a human tester 2–3 days happens in minutes.
Intelligent internal API testing. The agent systematically tests every internal API endpoint it can reach. It doesn’t just fuzz parameters; it tests authorization logic, attempts cross-service access, validates authentication requirements, and checks for BOLA/IDOR across object references. It understands which endpoints handle sensitive data (payment, PII, credentials) and applies deeper testing to those.
Service mesh validation. The agent probes service mesh policies by attempting connections that should be blocked, testing mTLS validation, checking whether the mesh enforces authorization rules, and identifying services that bypass the sidecar proxy. This is the kind of systematic validation that no team can do manually across hundreds of services.
Secrets and credential discovery. The agent searches for exposed credentials in environment variables, Kubernetes secrets, container image layers, config maps, and mounted volumes. It attempts to use discovered credentials to access additional services, databases, and cloud resources, mapping the actual blast radius of credential exposure.
Attack chain simulation. Based on initial findings, the agent chains vulnerabilities together. A misconfigured network policy + an unauthenticated internal API + a database connection string in an environment variable = a path from initial compromise to data exfiltration. The agent identifies these chains automatically, producing findings that demonstrate real-world impact rather than isolated technical issues.
Watch AI Agents Map and Test 200 Internal Services in Hours
You just read how AI-driven pentesting handles service discovery, internal API testing, mesh validation, and attack chain simulation. See it run against a real microservices environment — from first scan to chained exploit.
Service meshes (Istio, Linkerd, Consul Connect) are supposed to enforce mTLS, traffic policies, and authorization rules between services. In practice, mesh configurations are complex and often misconfigured.
Test 1: mTLS enforcement. Attempt plain HTTP connections between services. If the mesh is configured correctly, plain HTTP should be rejected. In permissive mode (which is the default for Istio), both HTTP and HTTPS are accepted, meaning the mesh provides encryption only when both sides cooperate, not as an enforced policy.
Test 2: Authorization policy coverage. Review authorization policies for completeness. Are there wildcard rules (allow all from namespace X)? Are there services with no authorization policy at all (default-allow)? Does every inter-service call require a valid identity?
Test 3: Sidecar bypass. Can a pod communicate on localhost to bypass the sidecar proxy? Can init containers or privileged pods reach other services without going through the mesh? If sidecar injection is namespace-based, are there namespaces where it’s disabled?
Test 4: Control plane security. Can unauthorized users access the Istio/Linkerd control plane APIs? Can they modify traffic policies, inject sidecar configurations, or read TLS certificates?
AI pentesting agents can systematically run these tests across every service in the mesh. The alternative (manually testing mesh policies for 200 services) is why most organizations never validate their service mesh security at all.
Container and Kubernetes security testing is inseparable from microservices pentesting. The orchestration layer is part of the attack surface.
Container image scanning is necessary but not sufficient. Tools like Trivy and Grype catch known CVEs in dependencies. What they don’t catch: hardcoded secrets baked into image layers, overly permissive file permissions, unnecessary SUID binaries, running as root when unprivileged operation is possible, and debug tools left in production images.
Kubernetes RBAC testing checks whether service accounts have minimum necessary permissions. Common findings: service accounts with cluster-admin, pods that can list secrets across namespaces, default service account tokens mounted into pods that don’t need Kubernetes API access, and CI/CD service accounts with write access to production namespaces.
Pod security testing validates runtime constraints. Can pods run as root? Can they mount the host filesystem? Can they use host networking? Kubernetes Pod Security Standards (Baseline, Restricted) define what should be enforced, but enforcement requires either Pod Security Admission or a policy engine like Kyverno/OPA Gatekeeper. Testing whether these controls are actually enforced (not just configured) requires attempting the restricted actions.
Network policy testing verifies that limit pod-to-pod communication. The default in most clusters is allow-all. Even when NetworkPolicies are deployed, gaps are common: policies that don’t cover all ports, egress rules that allow internet access from sensitive pods, and missing policies in non-production namespaces that share the cluster.
An AI pentesting agent running inside the cluster tests all of this systematically. It enumerates RBAC bindings, attempts privilege escalation through service accounts, tests network reachability between namespaces, and validates pod security constraints by attempting restricted operations. Coverage that would take a Kubernetes security specialist weeks to perform manually.
Get a Custom Microservices Pentest Scoped to Your Architecture
Container security, Kubernetes RBAC, network policies, service mesh validation — your microservices stack needs testing that covers all three rings of the attack surface. Book a 30-minute demo to see Agent Shell inside your cluster. Tell us about your architecture and we’ll tailor the walkthrough.
by putting the AI agent where it needs to be: inside your environment.
Agent Shell deploys inside your cluster. Instead of testing from outside, Strobes connects from within your Kubernetes cluster, VPC, or internal network. The agent gets the same network position as your microservices, so it can reach internal APIs, message queues, and databases. No inbound firewall holes required. The connection is outbound-only to Strobes SaaS.
Complete service mapping. The agent maps every service, its ports, protocols, dependencies, and authentication mechanisms. It pulls from Kubernetes API, cloud provider metadata, service mesh registries, and DNS. This map becomes the testing scope, automatically, not through a manual scoping call.
East-West traffic testing at scale. The agent tests inter-service APIs with the same rigor applied to external APIs: OWASP Top 10, authorization checks, injection testing, and authentication validation. But it does this for internal APIs that external pentesters never reach.
Supervisor Mode for production safety. Running security tests inside a production microservices environment requires caution. Strobes Supervisor Mode (User) lets you approve each test step before execution. Start with User mode to build confidence. Transition to Auto mode for staging or pre-approved test categories. Auto-approval rules give you granular control: approve read-only tests automatically, require manual approval for write operations.
Continuous testing with scheduled runs. Set up weekly or monthly that re-test your microservices environment and diff against previous results. New services get discovered and tested automatically. Fixed findings are verified. Regression is caught early.
You can test the perimeter (API gateway, public endpoints) from outside, but you’ll miss 80–90% of the microservices attack surface. Effective microservices pentesting requires internal access to test East-West traffic, inter-service authentication, Kubernetes security, and service mesh policies. Agent Shell provides this without opening inbound firewall ports.
For a 100–200 service environment, a full AI-driven pentest covering perimeter, internal APIs, Kubernetes, and service mesh typically completes in 6–12 hours. The equivalent manual effort would be 4–8 weeks with a specialized team.
Both, but differently. Test staging aggressively, because that’s where you find vulnerabilities before they reach production. Test production carefully using Supervisor Mode (User) to validate that production-specific configurations (network policies, RBAC, service mesh) are secure. Production-specific misconfigurations won’t appear in staging if the environments differ.
Strobes AI agents use a combination of Nuclei, nmap, custom API testing scripts, Kubernetes client libraries, service mesh CLI tools, and proprietary testing logic. The agent selects tools based on what it discovers; gRPC services get different tools than REST APIs. You can see every tool invocation in the workspace activity log.
Event-driven architectures (Kafka, RabbitMQ, SQS) require testing the message producers and consumers for injection, deserialization flaws, and authorization. AI agents can publish test messages to queues and observe consumer behavior, test message schema validation, and check whether consumers authenticate message sources.
No. Black-box testing from the internal network position is the primary approach. Source code access (white-box) improves coverage for business logic testing and helps identify hardcoded secrets. Strobes supports both approaches: point it at your GitHub/GitLab repo for code-assisted testing, or run purely network-based without source access.
Written by the Strobes Security Research Team. Our offensive security researchers specialize in cloud-native and microservices security testing across AWS, GCP, and Azure environments.
