The container sprawl nobody inventories
Containers are the default unit of local development. A developer runs docker compose up and a stack of services materializes: a database, a couple of APIs, a message queue, maybe an admin dashboard and a cache. It is fast, reproducible, and exactly what we wanted from containers.
It also creates a sprawl of local services that almost no organization inventories. Each container may bind a port. Each exposed port is a reachable service. And in the AI agent era, “reachable” now includes “reachable by an autonomous tool running on the same machine.”
This is shadow IT in container form: real services, with real data, exposed on developer machines, with no central register and no policy on who — or what — may reach them.
What containers actually expose
Look at a typical development stack and consider what is listening:
- A Postgres or MySQL container with seed data that often resembles production.
- Internal APIs and microservices under active development.
- Message queues and brokers (Redis, RabbitMQ, Kafka).
- Admin and observability dashboards.
- Object storage emulators holding test artifacts.
Each of these was started for a good reason. Collectively, they form a private services environment on the laptop — and an AI agent debugging a test or “helping” with an integration can query the database, call the API, or hit the dashboard directly. None of that traffic necessarily crosses a network control point.
Why this is a security problem now
Three factors turn ordinary container sprawl into a governance gap.
Agents can reach local services. The same convenience that makes containers great for developers makes them reachable for agents. An autonomous tool with local network access does not distinguish between a service you intended it to use and one you did not.
Exposure is easy and silent. Publishing a port, binding to 0.0.0.0, or forwarding through a tunnel can widen exposure far beyond the developer’s intent — sometimes to the whole network. The default is convenience, not containment.
There is no inventory or audit. Ask which containers and exposed services exist across the fleet, which hold sensitive data, and which AI tools can reach them. The answer is almost always unknown.
From shadow to governed
The fix is not to ban containers — that would be absurd. It is to turn shadow containers into governed developer services through a repeatable pattern:
Discover, read-only. Detect running containers and Compose stacks through the Docker-compatible socket, and do it read-only — bypassing secrets and environment variables. The goal is an inventory of services and exposed ports, not a copy of anyone’s code.
Classify. Identify what each service is. A database, an admin dashboard, and a stateless API carry different risk and deserve different policy.
Govern access. Decide which agents and identities may reach which services. Deny unknown local services by default; require approval before sensitive ones are reachable.
Control exposure. When a service genuinely needs to be shared — a demo, a teammate, a webhook — route it through an approved, outbound-only tunnel rather than an open inbound port, with policy and audit. This converts an ad-hoc, invisible exposure into a governed, reviewable one. See Secure Reverse Tunnel for Private Developer Services.
Audit. Record who exposed what, which agent accessed which service, and under which policy.
Where Cup’n’String fits
Cup’n’String auto-discovers Docker via the Docker-compatible socket (docker.sock, DOCKER_HOST, docker context) and detects containers and Compose environments read-only. It extends the same model to Apple Container, OrbStack, Podman, and local Kubernetes clusters. Discovered services can be inventoried, governed by policy for AI agent access, and exposed when needed through secure outbound-only tunnels (gRPC/WebSocket over TLS) that require no inbound ports — all with audit evidence.
See Docker Desktop Governance, Apple Container Governance, and the Docker Desktop comparison for how this complements, rather than replaces, your container runtime. Discovery is read-only and enforcement is strongest when paired with host firewall and network controls.
Checklist
- Can you discover containers and exposed services across the fleet, read-only?
- Can you classify what each local service is?
- Can you control which AI agents reach which services?
- Can you replace ad-hoc port exposure with governed tunnels?
- Can you require approval before exposing sensitive services?
- Can you audit container exposure and access?
Make the data center on the laptop a managed one
Containers gave every developer a personal data center. That was a productivity win and, until recently, a contained risk. AI agents removed the containment by becoming a new, autonomous consumer of those local services. The answer is the same one that worked for cloud sprawl: inventory it, govern access to it, control exposure, and audit it. Do that, and the container stack on the laptop stops being shadow IT and becomes a governed part of your developer environment.