It starts with an .env file - nothing big, just a single line, you can’t even see it in a normal ls command.
A developer needs an API key to get access to an LLM, and it works. Then that key or another one is in a CI pipeline, or a container image. Suddenly, autonomous agents are a thing, so the agent gets a key, so it can call APIs, invoke tools, and run subroutines, all without a human anywhere near the work.
“Just one key” works, and seems reasonable, at the scale of one developer. But soon credentials are scattered across machines, pipelines, and runtimes. If someone has questions about who accessed which database with what models, nobody quite knows. And your auditors probably don’t want the answers from an agent.
This situation is something enterprise engineering teams are in today, and more so every day. It’s not something you solve with more docs or security warnings. It’s an architecture problem, one Tailscale kept hearing about in conversations with customers and other tech founders. It’s the problem that led us to build Aperture.
How you, and everyone else, got here
AI key sprawl isn’t new, but the velocity has increased. AI tooling is being adopted faster than almost any previous category of developer infrastructure, and it’s being adopted in a way that compounds the credentials problem rather than solving it.
The first developers at a firm, experimenting with LLMs, generate personal keys. Suddenly a team, or a whole department, wants access, on multiple machines, and a decision-maker has to choose between parceling them out or making a “team key.” Either way, the keys get checked into the config files of a private repo, which is fine for the time being. Then CI needs it, so it’s a secret. Now an agent wants it. Next a staging environment, a production workload … every step makes situational sense.
So keys end up everywhere, and now it’s hard to say who is using them. Add autonomous agents to the picture, and it’s harder still to say what data was fed to which tools. You can review your provider's request logs, but they offer little context. You end up with data flowing outward through tools you weren’t expecting, and no real attribution, control, or audit trail.
That’s how you end up with reports showing that 34.8% of corporate data fed to AI tools is sensitive. Add to that a survey finding that 44% of workers have used AI at work in ways that go against organizational policies, like using public and free AI tools instead of managed subscriptions. The pressure to adopt AI quickly is real; how it often gets adopted is very messy.
It’s not about better locks and vaults
Secrets management exists, and it can better store and even rotate your keys. But that’s only half the problem.
Knowing where the key is stored helps, but it doesn’t tell you who is using it, when, from which workload, with which agents, models, and tools. The key is harder to lose track of, but you’ve lost track of which services are using it.
Better key storage is one fix. Eliminating the idea of the key being an identity is the redesign.
Identity at the network layer
From its very beginnings, Tailscale has sought to move organizations away from credential-based trust into an identity-based trust that’s baked into the network layer itself. Every node in a Tailscale network (tailnet) authenticates against your preferred identity provider. Laptops, ephemeral runners, Kubernetes pods, cloud VMs—all have verified identities, or else they can’t communicate. Access policies are enforced at each node, rather than at some checkpoint or firewall.
Aperture followed on as the next logical step for dealing with the tricky matters of AI traceability. Because every workload in a tailnet has an authenticated identity, the network knows which devices are talking among themselves, as well as calling outside. Putting Aperture on your tailnet means having one place to fulfill LLM requests, and getting a central record of who is calling what models, when, and how they use tokens.
What Aperture actually does
Aperture is an AI gateway that sits inside your tailnet. It gives you one place to keep the provider API keys your AI tools use. It works with OpenAI, Anthropic, Gemini, self-hosted, and most agents or frameworks with custom base URL support.
When a developer’s coding agent needs to talk to a model, it sends the request through Aperture’s endpoint. Aperture authenticates that request through a Tailscale identity—user:alice@example.com or tag:pr-review–bot—and forwards it to the LLM provider.
Clients don’t hold credentials. Keys don’t leave the gateway. Rotations happen inside Aperture, where they don’t break every workflow that depends on them.
The logs don’t look like “Some kind of request came from IP 10.1.x.y”; they say, “This user, this device, this request, to this model, at this time, with this token usage.”
If your preferred provider changes, Aperture adapts without touching your workflows or credentials.
With a central point of control and authentication for AI requests, you can set policies on which teams get which providers and models, set spending limits, limit tool calls, and strip out PII. You don’t have to rebuild your security workflows or architectures. You give a developer access to Claude Code with the Opus model, and they never need to manage any credentials.
Agents make this more urgent
As AI moves from chat tools to assistants and agents, the need for better monitoring and guardrails gets stronger. When a developer is in the seat, things that seem askew can be stopped. When an agent is working autonomously, with real permissions, failure modes are harder to observe, and the fallout wider in scope.
Anthropic itself has called out the dangers of deploying AI “in roles with minimal human oversight and access to sensitive information.” You could try avoiding agents, but they’re the space where productivity gains seem far more real than general applications. If you can track every agent request back to its origin, and scope their minimum necessary access, you’ve got a better shot at understanding the risks and investigating their actions.
Networks that don’t become liabilities
There’s a broader design issue here that reaches beyond AI access. It’s how platform teams should think about network architecture in general.
Networks built on perimeter trust will always struggle to scale. “Inside the perimeter means it’s trusted” requires maintaining the perimeter, perfectly, forever, as the network grows more and more complex and distributed. Each new cloud region, every API integration, every agent experiment—all of them need shepherding inside the perimeter, or want an exception to stay outside. Access requires more institutional knowledge than any one mind can hold.
Networks built on identity scale more easily. Topologies can change, network locations may shift, but access models stay coherent and readable. It doesn’t become easy to add AI agents, per se, but access models can more easily cover them.
Going deeper
If you want to check out Aperture, it’s now self-serve, and available on free Personal plans, during its beta period. The same goes for Tailscale, where you can start with unlimited devices, 50 tagged resources, and 6 users, to see how it works.
If you want to go deeper on scalable network design, segmentation, zero trust access and keeping infrastructure manageable as it grows, Jay Stapleton is leading a Platform Engineering webinar on exactly these topics. Register here.
