How Identity Became the Security Perimeter: A 30-Year History of Who We Trust

Thirty years ago, enterprise security had a relatively clear boundary. Employees came into an office, logged onto company-managed computers, and accessed applications running on infrastructure the organization controlled. Security teams could draw a reasonably clear line around what belonged to the business and what did not. Inside that line was trusted. Outside it was not.

That model worked because the technology environment largely supported it. Then the applications moved. The workforce moved. Infrastructure moved. Data moved. Identities multiplied. Eventually, many of those identities stopped being human altogether.

The security perimeter did not disappear overnight. It was gradually dismantled by decades of changes in how businesses operate and how technology is delivered. Each shift forced organizations to reconsider a fundamental question: Who, or what, should we trust?

Today, the answer increasingly comes back to identity. But getting here took 30 years, and understanding that evolution helps explain why identity security has to change again for the modern enterprise.

1995–2005: Trust the network

In the late 1990s and early 2000s, enterprise security largely revolved around a physical and network boundary. Employees worked from corporate offices, applications lived in corporate data centers, and devices were purchased and managed by IT. Active Directory, introduced by Microsoft in 1999 and released with Windows 2000 Server, helped organizations centralize how users and resources were managed within that environment.

The security model was relatively intuitive: protect the network, authenticate employees as they entered it, and control what they could reach once they were inside. Firewalls separated trusted internal networks from the public internet. VPNs extended that trusted environment to employees who needed remote access. Directories gave organizations a centralized way to manage users, groups, and permissions.

Identity mattered, but network location carried significant trust. If a request came from a corporate device on the corporate network, there was an underlying assumption that it was more trustworthy than something coming from the outside. The network was the perimeter, and identity was one of the mechanisms used to enter it.

Then applications began leaving that perimeter.

2005–2015: Identity becomes portable

The rise of software as a service changed where work happened. Applications that once lived inside company infrastructure increasingly lived somewhere else. Salesforce, Google Workspace, Box, and thousands of other cloud applications allowed employees to access business systems without ever touching the traditional corporate network.

Businesses adopted them quickly. In 2016, Okta reported that its average customer was already using 13 cloud applications. By 2025, the average number of applications per Okta customer had surpassed 100.

That growth changed more than the software stack. If an employee could open a laptop at home and authenticate directly to a SaaS application hosted by a third party, being inside the corporate network stopped being a prerequisite for accessing company data. Identity became portable, and single sign-on, federation, multi-factor authentication, and cloud identity providers became increasingly important because organizations needed a way to establish trust when the application, user, and device might all exist beyond the traditional perimeter.

The security question began shifting from “Is this request coming from inside our network?” to “Who is making this request?” But that shift introduced another challenge. Every new application created another place where identity had to be understood, accounts had to be provisioned and deprovisioned, and permissions could accumulate over time. Authentication was becoming more centralized, while authorization remained distributed across an expanding collection of systems.

Identity was becoming the connective tissue of the enterprise. It was also becoming one of its most complicated attack surfaces.

2015–2020: Zero Trust changes how we think about access

By the second half of the 2010s, cloud adoption, mobile work, BYOD, and distributed infrastructure had made the old distinction between inside and outside increasingly difficult to defend. Zero Trust offered security teams a different model.

When NIST published its Zero Trust Architecture guidance in 2020, it described a shift away from static, network-based perimeters toward users, assets, and resources. It also established that implicit trust should not be granted simply because a user or device is physically or logically located within a corporate environment. That represented a significant change in how organizations thought about security: location alone was no longer enough to establish trust.

A user was not inherently trustworthy because they were sitting in an office. A laptop was not inherently trustworthy because IT owned it. A connection was not inherently trustworthy because it originated from the corporate network. Trust increasingly depended on context: who the user was, what device they were using, what resource they were trying to access, how they had authenticated, and whether the request made sense.

Identity moved closer to the center of security architecture because the network could no longer answer those questions on its own. But even then, much of the identity model was built around a familiar assumption: the identity was a person.

Employees joined a company, were assigned roles, received accounts and permissions, changed jobs, and eventually left. Identity governance and administration (IGA) developed around this human lifecycle for good reason. For much of enterprise computing, the employee was the primary identity organizations needed to govern.

That was about to change.

2020–2024: Attackers stop needing to break in

As identity became more important to legitimate access, it also became more valuable to attackers. Passwords could be stolen. Sessions could be hijacked. MFA could be bypassed or socially engineered. OAuth tokens could provide persistent access. An overprivileged account could turn an initial foothold into a much larger compromise.

The distinction between an attacker and an authorized user becomes much harder to make when both can present valid credentials. This period reinforced an important limitation of authentication: proving that an identity successfully authenticated answers only one part of the trust question.

Authentication does not tell you whether the access an identity holds is still appropriate. It does not tell you whether a permission granted two years ago remains necessary, whether an account should still exist, or whether the person using a valid credential is actually the person to whom it was issued. As identity became the pathway into more applications and infrastructure, access itself became an increasingly important part of the security problem.

At the same time, the number and types of credentials throughout enterprise environments were exploding. API keys, access tokens, certificates, service account credentials, and other secrets became embedded throughout cloud infrastructure, CI/CD pipelines, repositories, applications, and automation. GitGuardian detected roughly 11 million new secrets in public GitHub commits in 2021. By 2025, that number had reached nearly 29 million, an increase of 152% in four years.

The perimeter was no longer simply following the employee. It was following every identity and credential capable of reaching an enterprise resource.

2024–today: The identity is no longer necessarily human

This is where the identity story changes again.

Modern enterprises now depend on enormous populations of identities that will never log into a laptop, receive a badge, report to a manager, or appear in an HR system. Service accounts authenticate applications. Workloads communicate with other workloads. APIs call other APIs. Automation executes business processes. Bots interact with systems. Certificates establish machine trust. AI agents increasingly access data, invoke tools, and take actions on behalf of users and organizations.

These are identities too, and there are a lot of them. Palo Alto Networks' 2026 Identity Security Landscape, based on a survey of 2,930 cybersecurity leaders, found that machine identities now outnumber human identities 109 to 1. The same research found widespread adoption of AI agents, creating another rapidly expanding identity population that organizations need to secure and govern.

The scale is significant, but the larger challenge is that these identities do not follow the governance model organizations spent decades building around employees. HR knows when someone joins a company. A manager understands their role. A promotion or department change creates a lifecycle event. A termination creates another. Those events provide natural triggers for provisioning, access changes, reviews, and deprovisioning.

A service account does not have a manager. A workload does not leave the company. An API key does not get terminated through HR. An AI agent may be created for a specific purpose, connected to several systems, given access to enterprise data, and then continue operating long after its original use case changes.

The fundamental identity security questions, however, remain remarkably similar. Organizations still need to know what an identity is, who owns it, what it can access, why it has that access, whether the access is appropriate, and when that access should change or disappear. What has changed is the population to which those questions apply.

Modern identity security therefore cannot maintain one governance model for employees and treat every other identity as an exception. Human, non-human, and AI identities need to be brought into the same security and governance framework, with the controls appropriate to how each identity actually operates. This is the model Linx describes for agentic identity governance: no separate governance program and no separate set of principles, but consistent ownership, access reviews, policy enforcement, least privilege, and lifecycle management across identity types.

AI agents change the trust question again

AI agents push this evolution one step further because they introduce something many previous machine identities did not have: agency. A service account may authenticate one system to another, and an API key may authorize a defined integration. An AI agent can interpret a goal, determine a sequence of steps, access multiple systems, invoke tools, interact with data, and take actions along the way.

For decades, identity security largely focused on determining who could access what. AI agents force organizations to ask an additional question: What is an identity allowed to do once access has been granted?

An employee may have permission to access a customer database. An AI agent acting on that employee's behalf may have access to the database along with email, a CRM, file storage, and other tools required to complete an objective. Each individual permission may be legitimate, while the combination of those permissions and the actions the agent can take with them creates an entirely different level of risk.

That is the gap AI access control is beginning to address. It is not enough to know that an agent is authenticated or that it can connect to an application. Security teams need visibility and control over the actions the agent takes after that connection is established, including which tools it invokes, what data it touches, and whether the action should be allowed in the context of the identity behind the request.

This is the principle behind Linx AI Access Control, which extends identity policy into the agentic layer and applies real-time enforcement to agent actions. It evaluates MCP tool calls before they execute and connects those actions to the identity context behind the request, allowing the same governance logic used across human and non-human identities to extend to AI agents.

The technology has changed, but the identity problem is familiar. Organizations need to understand who or what is acting, what authority it has, where that authority came from, whether the requested action is appropriate, and who is ultimately accountable for it.

The identity perimeter is a web of relationships

There is another lesson hidden in this 30-year evolution: identity risk rarely exists within a single account or permission.

A person may have an identity in an identity provider that maps to dozens of SaaS accounts. Those accounts have roles and entitlements. The person may own a service account with its own credentials and permissions. That service account may reach cloud infrastructure. An AI agent may act on the person's behalf while using its own credentials to invoke tools with entirely different permissions.

The risk lives in the relationships between them.

This is why modern identity security requires more than an inventory of users and accounts. Security teams need to understand how identities, accounts, permissions, resources, owners, credentials, and access paths connect across the environment. A permission that looks reasonable in isolation may create a very different risk when viewed as part of the full access path.

It is also why disconnected identity tools struggle to provide the full picture. Authentication may live in one platform, governance in another, privileged access somewhere else, application permissions inside individual SaaS tools, and machine credentials across cloud infrastructure and developer environments. Each system can tell part of the story, but security teams increasingly need to understand the relationships between all of them.

The evolution from network perimeter to identity perimeter is therefore not simply a story about moving a security boundary from one place to another. There is no new wall around identity. The modern identity perimeter is dynamic, distributed, and constantly changing.

Trust has to become continuous

For most of security's history, trust has been treated as something that could be established at a point in time. A user entered the correct password, passed MFA, connected from an approved device, or received approval for access. Each represented a decision that, in some way, said the organization trusted that identity to proceed.

Modern identity environments make those decisions increasingly temporary. Employees change roles, contractors finish projects, service accounts stop being used, workloads are replaced, permissions become excessive, credentials leak, and AI agents take on new responsibilities. An access decision that was appropriate yesterday may no longer make sense today, even when the identity and credential remain valid.

That means identity security can no longer focus solely on establishing trust at login or periodically checking whether access remains appropriate. Organizations need to continuously understand identity, access, relationships, ownership, usage, and risk as those conditions change. Governance has to remain current with the environment it is governing.

This is also where AI-native identity security changes what is possible. Traditional governance has relied heavily on scheduled reviews and manual workflows because security teams could not continuously evaluate every identity change and access decision themselves. AI can help shift that model from periodic identification of risk toward continuous evaluation and action, while still keeping people involved where judgment or oversight is required.

The next era of identity security

The last 30 years tell a remarkably consistent story. When work happened primarily inside corporate environments, organizations trusted the network. As applications and employees moved beyond that perimeter, identity became the portable control point. Zero Trust challenged the assumption that location should confer trust, while cloud, SaaS, automation, and modern software development dramatically expanded the number and types of identities organizations needed to secure.

Now that evolution is accelerating again. Human identities operate alongside service accounts, workloads, APIs, non-human identities, and AI agents. Some of those identities can independently access systems, use tools, interact with sensitive data, and take actions. The security question is no longer simply whether an identity successfully authenticated. Organizations increasingly need to understand what the identity is, who or what owns it, what access it has, why it has that access, how its permissions relate to other identities and resources, what it is doing with that authority, and whether that access should still exist.

This is the modern identity era. The fundamentals of identity security have not disappeared, but the environment in which they operate has changed. Identity security now has to account for every identity type, understand the relationships that create access and risk, continuously govern changing permissions, and take action when access no longer aligns with business reality.

Identity security built for the modern identity era

Linx was built for this environment. As an AI-native identity security and governance platform, Linx brings human, non-human, and AI identities into the same security and governance framework rather than requiring organizations to manage separate identity programs as new identity types emerge.

At the foundation is the Linx Identity Graph, which continuously maps identities, relationships, and access paths across the environment rather than relying on a point-in-time snapshot. That context allows organizations to understand who has access, how that access was gained, how identities and resources are connected, and where those relationships create risk. Linx then brings governance into that same context, with access requests, reviews, policies, lifecycle management, and remediation informed by actual identity risk and business impact.

That approach applies across the identity lifecycle. Employees still need joiner, mover, and leaver processes, access reviews, least-privilege controls, and lifecycle automation. Non-human identities need ownership, purpose, access governance, and lifecycle management even when they do not originate in HR. AI agents need those same identity disciplines, along with controls over the actions they take with the authority they have been given. Linx brings those identities into one framework so organizations can govern the entire identity environment rather than creating a new security silo every time the definition of identity expands.

Linx also moves identity security beyond periodic governance. Autopilot continuously monitors the identity environment for high-impact changes, evaluates risk using the context of the Identity Graph, and acts when it should, either remediating risk autonomously or escalating decisions when human oversight is warranted. Instead of waiting for the next scheduled review to discover that access has drifted, organizations can continuously identify and address changes as they happen.

And as AI agents become active identities inside the enterprise, Linx AI Access Control extends that governance into the actions agents take. It provides real-time visibility and enforcement over agent activity, evaluating individual tool calls and applying identity policy before actions execute. This allows organizations to bring AI agents under the same identity discipline already applied to human and non-human identities while addressing the additional risk created when an identity can act autonomously.

Thirty years ago, the network told organizations where to place trust. Today, trust is distributed across a constantly changing ecosystem of people, machines, applications, permissions, resources, and AI agents. Securing that environment requires an approach built around the reality that identity is no longer one type of user, one account, or one point-in-time access decision.

That is the modern identity era, and Linx was built for it.

Ready to see what modern, AI-native identity security looks like in practice? Book a demo with Linx to see how Linx unifies security, governance, and access across the entire identity lifecycle.

Frequently asked questions about identity security

What is the identity security perimeter?

The identity security perimeter describes the shift from relying primarily on network location to using identity as a central control point for securing enterprise access. As users, applications, infrastructure, and data have moved beyond traditional corporate networks, organizations increasingly rely on identity, access, context, and governance to determine who or what should be trusted.

Why has identity become the new security perimeter?

Cloud computing, SaaS, remote work, APIs, and distributed infrastructure have made the traditional network boundary less representative of how enterprise resources are accessed. At the same time, attackers increasingly target credentials, sessions, permissions, and other identity mechanisms to gain legitimate-looking access. As a result, identity has become central to determining who or what can access enterprise resources and whether that access remains appropriate.

What is modern identity security?

Modern identity security brings visibility, governance, lifecycle management, least privilege, access control, and remediation together across the identity environment. It extends beyond workforce users to secure and govern human identities, non-human identities, and AI agents across SaaS, cloud, on-premises, and hybrid environments.

How is modern identity security different from traditional identity security?

Traditional identity programs were largely designed around workforce users and predictable employee lifecycles. Modern identity security retains those fundamentals while extending governance to service accounts, workloads, other non-human identities, and AI agents. It also uses continuously updated identity context, risk-based governance, automation, and remediation rather than relying primarily on point-in-time reviews and manual processes.

Why do non-human identities need identity governance?

Non-human identities can hold significant access to applications, infrastructure, and sensitive data, but they often lack the lifecycle signals associated with employees. Effective governance requires organizations to understand why each identity exists, who owns it, what it can access, whether that access remains appropriate, and when the identity or its permissions should be removed.

How do AI agents change identity security?

AI agents can do more than access information. They can invoke tools, interact with multiple enterprise systems, and take actions using the authority they have been given. Organizations therefore need to govern both the agent's identity and access and the actions it takes, including connecting those actions to the human or identity context behind them and enforcing policy before inappropriate actions occur. Linx AI Access Control is designed specifically for this real-time governance layer.

What is AI-native identity security?

AI-native identity security uses AI as part of the underlying approach to understanding, governing, and acting on identity risk rather than simply adding AI features to an existing identity platform. Linx uses the continuously updated context of its Identity Graph alongside AI-driven governance and Autopilot to evaluate identity changes, prioritize risk, automate governance, and remediate appropriate risks while escalating decisions that require human oversight.

How does Linx approach modern identity security?

Linx is an AI-native identity security and governance platform built to secure and govern human, non-human, and AI identities in one framework. The platform combines the Linx Identity Graph, risk-centric governance, lifecycle management, automation, autonomous identity security through Autopilot, and real-time AI agent governance through Linx AI Access Control.