From WAM to Agentic Access Management: History is Repeating Itself
The 90s problem: web application explosion
Back in the 90s, as the web was taking off, a new category of security products emerged: web access management (WAM). It became essential for governing the multitude of web applications enterprises were rushing to deploy and secure.
But why was it needed at all? Commercial off-the-shelf (COTS) applications already shipped with their own authentication provisions. Teams building customer applications could write their own authentication and authorization codes into the application. On paper, every application could secure itself.
In practice though, securing an application properly is extremely tricky. Other than keeping up with ever changing security landscape that requires constant attention, different teams bring very different levels of security skills. Some get it right; many get it wrong, and each gets it wrong in its own way.
What WAM changed: security moved out of the app
Security moving out of the application did not mean not using secure practices to write an application but rather WAM let developers focus on their applications business logic and delegated the complex function of properly security their application to solution that specializes in security applications.
The contract was simple. If a request reached the applicaiton, it has already passed though the security layer. Only traffic that cleared authentication and authorization ever got to the app and the app could consume the authorization hints to expose data and views. Security became a property of the infrastructure, not a feature every team had to rebuild.
WAM was a major win for enterprises trying to secure a growing sea of applications, and it paid of twice:
For developers: relief from the heavy lifting of designing authentication and authorization in every app
For corporate IT security: one place to define policy that was enforcable and auditable so that application could be secured and governed centrally.
The approach became standard. Few fortune 100 organization ran without a WAM solution. Mention SiteMinder to an enterprise security team and they will likely recall protecting critical application with it or a stack just like it.
Identity centralized, enforcement scattered
Starting in the later 2000s a second pattern came into prominence.With SaaS, APIs, microservices and the cloud meant it was not easy for calls to pass through corporate gateways. WAM proxies also had real costs where it was not easy to scale or deploy fast enough to keep up with the growth. Many applications used native LDAP integrations along with SAML, OAuth and Open ID. These integrations fit that distributed world. But there is a shift and trade-off that is easy to miss.
Authorization went back into the app. Every team again implements its own authorization token verifications and checks with uneven skills.
The application is directly exposed. The purpose built security barrier no longer fronting the application and the attack surface just got bigger.
Policy scattered across code. Security teams lose central place to define, change, and audit access.
Distributed security infrastructure support had been lagging. Even though cloud platforms were now serving applications with micro services in play, it took a while for security vendors to catch up with purpose built, cloud-native solutions that could be spun up rapidly. Infrastructure as code changed the deployment limitations and the constraint is now largely gone. With autoscaling infrastructure, enforcement can be run at the edge, policies stay central while enforcement scales out with a distributed architecture.
Note that SAML, OAuth, OpenID Connect standards are essential to the authentication and authorization ecosystem and they are what allows policy to stay central while enforcement scales out. An enforcement layer, provided by a security vendor, can securely validate the token and assertions, applying policies consistently without weakening security.
The agentic era
This era has brough about a shift in the developement patterns. Teams are building agentic applicaions, where an agents capability are packaged as tools it can call. A large language model (LLM) reads the users request and decides which tool to use, and in what order, to fulfil it.
Just as teams in the 90s build web applications, teams today are using and building tools for agents. These tools connect agents to the organizations applications and data so they can take meaningful action inside the enterprise.
Similar pattern, 30 years later
Developers are building security into each agent and tools servers themselves. that is the 90s pattern all over again: the burden of seuring the agentic tier falls on whicever team happens to build it.
The stakes are much higher this time:
The caller is not-deterministic. An LLM, not a fixerd code path, decides which tool runs. Prompt injection or a misread request can steer it towards actions nobody intended.
Identity is layered. Every call involves a user, an agent action for that user, and a tool action on a downstream system. Each hop has to carry the right identity and the right scope.
Service accounts are in use. There are use cases where the only option is to use a service account. How to handle appropriate actions when the intended authorizations varies based on the user invoking an agent? For SaaS accounts, management of per user keys and authorizations can become very tricky very quickly.
Tools take action. This is not just a conversation with a user. Tool actions provide a direct path into enterprise systems and proper authorizations must be in place that are manageable.
Policy is scattered. Each team trying to secure their agents and tools for an application, so security teams have no easy way to determine security policies in play for an agent or application.
Central Visibility is lacking. When teams are building their own authorization layers for the toolset, those same challenges, and more, come back in as in the 90s with the explosion of web.
The answer then is the answer now: delegate it
The lessons from WAM applies directly in the agentic era. Tool developers should focus on what their tools do, and let the dedicated agentic access layer handle securing the agentic eco system. If a tool call reaches the tool, it has already been authenticated, authorized, and logged.
An agentic access layer should:
Authenticate every party. Verify a pre-authenticated users and require authentication for agents.
Propagate delegated identity, so appropriate authorizations are granted to an agent that can work in autonomous or delegated mode with appropriately scoped credentials.
Authorize each tools call against central policies, at the level of sprcific action and date involved, not just "can this agent reach this tool service."
Runtime visibility and control is essential in this agentic era where access and authorizations can change rapidly.
Record a full audit trail linking each action back to the user request and agent that triggered it.
WAM gave enterprises the confidence to put hundreds of applications on the web. A central access management layer for agents does the same for the agentic era - let teams build agents and tolls quickly while security teams keep one place to set policies. Organizations that learned this lesson in the 90s should not have to learn it again.
There are plenty of solution emerging in this space. Broadcom's AgentMinder stands out with a robust agentic fabric that has been generally available since August 2026. It is cloud native and built to scale which runs on Kubernetes across on-prem, private and public clouds and integrates with existing authorization stacks though the AuthZEN standard. Central policy with enforcement is a foundational security pattern and a solution that scales while doing so is worth looking into.