👉 TL;DR: The perimeter has moved before. It went from the network to identity, the shift everyone summarized as "identity is the new perimeter." It is moving again, onto the device.
Open a developer's laptop, and you will find a stash of working credentials: cloud access keys, API tokens, SSH keys, package-registry tokens, and the secrets AI coding agents cache as they run. Network controls never see them. The identity provider decides who can log in, but not which valid keys are already on the disk. EDR watches process behavior, not the plaintext credential sitting in a config file. The credentials are present, valid, and reusable, but no layer in the stack is responsible for inventorying them.
The next phase of perimeter security starts with visibility into the credentials already sitting on the developer endpoint, before they become someone else's access.
The perimeter keeps moving
For thirty years, "securing the perimeter" has meant defending the boundary around access. First, that boundary was the corporate network. Then it became identity. Now it is wherever valid credentials live.
Era 1: The network was the perimeter
In the first era, the perimeter was a place. Firewalls, VPN concentrators, and network segmentation separated the trusted inside from the hostile outside. This was the castle-and-moat model that defined enterprise security for decades: get onto the corporate network and you were largely trusted; stay outside it, and you had to get through the wall first.
Cloud, SaaS, and remote work dissolved the trusted inside. Workloads moved to infrastructure the company did not own. Data moved into third-party applications. Employees signed in from kitchens and airport lounges. The assets worth protecting no longer sat behind a single boundary, so there was no single boundary left to defend. This erosion of the fixed network edge has a name: deperimeterization.
Era 2: Identity became the perimeter
With no fixed network edge, security shifted from where access came from to who was requesting it. Single sign-on, multi-factor authentication, conditional access, and the identity provider became the new control plane. This was the era of "identity is the new perimeter," and identity-first security is now the default for most mature programs.
It was the right move, but it left a deeper gap. An identity provider governs authentication. It can challenge a user signing in from an unusual location because the context looks wrong. But it does not inventory the valid credentials already resting on a device, and it cannot always tell whether a local access key is still being used by the identity it belongs to. If the key is valid and the access is in scope, there may be nothing anomalous to flag.
Era 3: The device is where the keys now live
Now the developer laptop is where those long-lived credentials pile up: cloud credentials in ~/.aws, Kubernetes configs in ~/.kube, API tokens in dotfiles, SSH private keys in ~/.ssh, package-registry tokens in .npmrc, and secrets AI coding agents write into config and temp files as they operate.
An attacker who reaches that endpoint does not need to break the identity system. The credentials already grant authorized access to cloud accounts, source control, package registries, and the SaaS tools the developer uses. There is no IdP exploit or password to phish. The attacker simply uses valid credentials as the trusted identity they belong to.
Agents make that surface even denser. A human may have location, device posture, or behavior patterns an identity system can challenge. Agents authenticate to systems constantly, often without a human in the loop, and with fewer contextual signals to evaluate. A valid credential can keep working long after anyone has context for why it exists.
That is what makes discovery the missing control here. You have to know which credentials are already on the device before someone else finds and uses them.
The credential plane on the developer endpoint is the new edge of the perimeter. It is also the one with the least dedicated coverage.
Why credentials pile up on the developer endpoint
Credentials pile up on developer machines because modern development rewards speed. Developers are expected to move quickly across cloud services, package registries, containers, source control, and AI tooling, and every repeated login slows that work down. So the tools optimize for convenience: every cloud login, container-registry login, and package-manager auth leaves a token behind in a config file so the developer does not have to authenticate again next time.
Vaults manage secrets at the source, but they do not control every local copy created after retrieval. A developer may pull a credential for local use, finish the task, and leave it behind in a file, cache, or shell history. That local copy becomes the exposure.
AI tooling adds another layer. Coding agents cache tokens, rewrite configuration, and drop secrets into temp files as they work. Each new agent or integration creates another identity and another place for a credential to land. Model Context Protocol (MCP) servers, agent skills, and local model tooling all expect credentials to be available on disk.
Many of these credentials are static by default. They are not tied to a session, and they do not disappear when the task ends. Unless someone rotates or revokes them, a key created for one local workflow can remain usable for months, sometimes years (for the mechanics of how this happens day to day, see protecting developers' secrets).
The attack path does not have to be sophisticated. A poisoned dependency or compromised editor extension lands on a developer machine and scans the places credentials usually live: ~/.aws/credentials, cached cloud sessions, SSH keys, old .env files, and shell history. Once those secrets are exfiltrated, the attacker can reach whatever they grant access to, from cloud accounts to private repositories to SaaS tools.
This is not hypothetical. In August 2025, the s1ngularity attack pushed malicious versions of the popular Nx build tool to npm, and its post-install script swept developer machines for SSH keys, npm and GitHub tokens, cloud credentials, and .env files. It was the first known attack to turn locally installed AI command-line assistants into accomplices, using them to help hunt down secrets before exfiltrating everything to public repositories. The self-replicating Shai-Hulud worm ran the same playbook across hundreds of npm packages. Neither attack had to break the perimeter. They went looking for what was already on the machine.
The gap: what network and identity controls don't see
Every layer in a mature stack watches a different part of the credential lifecycle. Each control below is valuable and necessary. But none is responsible for inventorying the plaintext credential on a device. That ownership gap sits between their mandates.
- Network security: watches traffic, connections, and egress. It does not see the access key in ~/.aws/credentials or the token in shell history, because a credential can exist on the device before it is ever used.
- Identity and access management (IAM): governs who can access what, usually through the identity provider (IdP) and its authentication and authorization policies. It does not enumerate the standing credentials already present on a machine.
- Privileged access management (PAM): stores and controls access to privileged credentials and sessions. The local copy a developer pulled to their laptop falls outside its scope.
- Endpoint detection and response (EDR): monitors the device for suspicious activity, malicious processes, and signs of compromise. It is built for detection and response, not for maintaining an inventory of credentials sitting in config files.
- Repo and CI secret scanning: inspect code and pipelines. They do not reach credentials on the local filesystem, whether those credentials are waiting to be committed or never enter a repository at all.
The future of the perimeter
Identity security and endpoint credential discovery are becoming harder to separate. One tells you which identities exist and what they can access. The other shows where the credentials for those identities are actually sitting. Together, they answer the question security teams increasingly need to ask: who, or what, holds access, and where does that access live?
AI agents will make the endpoint harder to control. Every new agent, integration, or local tool creates another identity and another place for a credential to land. As agentic development grows, credentials on the device multiply instead of disappearing.
Compliance will likely follow the same direction as the risk. Even when frameworks do not name endpoint credential discovery outright, they increasingly expect teams to account for exposed credentials, local secrets, and the paths those credentials create into critical systems.
All of this is changing the working definition of the perimeter. Network first, then identity, now the device. Each shift followed where access concentrated, and today that access increasingly sits on the developer endpoint.
Summary: the perimeter is wherever a valid credential sits
Network and identity controls are not going anywhere, and nor should they. But they also do not inventory the exposed credentials resting on the machine itself. Closing that gap means finding and revoking those credentials before an attacker uses them, and recognizing the developer endpoint for what it has become: part of the perimeter.
FAQs
Is the network perimeter dead?
The network perimeter is not dead, though it is no longer the boundary that matters most. Cloud, SaaS, and remote work dissolved the trusted inside. Protection moved first to identity and then to the device, where valid credentials now concentrate.
What does "identity is the new perimeter" mean?
With no fixed network boundary, identity (who is authenticating, and whether they are authorized) became the primary control plane. The framing is accurate but incomplete. Identity governs login events, not the standing credentials already sitting on devices.
Has the security perimeter moved to the endpoint?
The security perimeter has increasingly moved to the endpoint. The developer endpoint is where cloud keys, tokens, SSH keys, and AI-agent secrets accumulate. An attacker who reaches the device picks up valid, reusable credentials, which makes the endpoint credential plane the current frontier of the perimeter.
What is deperimeterization?
Deperimeterization is the long-running erosion of the fixed network boundary as cloud, mobile, and SaaS push assets and access outside it. The practical result is that protection has to follow identity and credentials wherever they live, including the device.
Does zero trust protect credentials sitting on a laptop?
Zero trust verifies access requests instead of trusting the network, which is essential. But it does not inventory credentials sitting at rest on a device, like a forgotten access key in ~/.aws.
Why isn't EDR enough to protect credentials on a developer machine?
EDR detects malicious processes and behavior. It does not inventory the plaintext credentials sitting in config files, caches, and shell history. Credential discovery is a complementary control that finds the secrets EDR was never designed to look for.
How is endpoint credential discovery different from identity security or ITDR?
Identity security and identity threat detection and response (ITDR) govern and monitor identities and authentication. Endpoint credential discovery inventories the actual secrets at rest on a device. One manages the identity. The other finds the standing credential that could compromise it.
How do attackers get valid credentials without breaching the network?
Attackers get valid credentials through infostealer malware on the endpoint, which reads cloud caches, shell history, SSH keys, and browser tokens. Because those credentials are valid, the attacker gains legitimately authorized access without ever touching the network perimeter.
