Enterprise Software (SaaS) • 21 hours ago • Neha Jamwal
Enterprise identity management was built around a relatively straightforward distinction. There were human users who needed accounts, applications that needed credentials, and service accounts that allowed software to communicate with other software. Security teams could assign permissions, review access, rotate credentials and eventually disable those identities when they were no longer required.
AI agents are making that model considerably more complicated. Unlike conventional automation, an agent can interpret a goal, make decisions, use multiple tools, retrieve information and take actions across enterprise applications with limited human intervention. It can behave like software, but it can also behave like a digital worker, creating an awkward gap between the identity models enterprises already have and the type of entity they are now deploying.
That gap is quickly becoming an enterprise security issue. In September 2026, Okta and a group of technology companies including AWS, CrowdStrike, Databricks, Google Cloud, Salesforce, ServiceNow, Wiz and Zscaler formed the Blueprint Alliance around a shared architecture for securing AI agents. One of the group’s central principles is to treat every agent as a distinct identity, with defined ownership, scoped access, traceable delegation and continuous monitoring.
The problem with treating an AI agent like another user
At first, giving an AI agent the same identity treatment as an employee sounds reasonable. Both need authentication, authorization and access to enterprise resources, but the similarity starts to break down once the agent begins operating autonomously.
A human employee generally has a defined organizational role, a manager, a job lifecycle and relatively predictable responsibilities. An agent can be created in minutes, connected to new tools, modified without changing its identity and given additional capabilities as its workflow expands. It can also operate continuously rather than waiting for someone to sit down and perform a task.
This distinction becomes particularly important in SaaS environments. An employee might use a CRM, collaboration platform, document repository and finance system during a normal workflow, but an agent could potentially connect to all of them directly and move information between them. The security team therefore needs visibility not only into who authorized the activity, but also which agent performed it, what permissions it had and which systems it touched.
Microsoft is already treating this as a distinct identity problem through Microsoft Entra Agent ID, which provides purpose-built identity constructs for AI agents and extends authentication, authorization, governance and compliance controls to these non-human identities.
Agent sprawl could become the next identity-management headache
Enterprise IT teams have already spent years dealing with application sprawl, SaaS sprawl and service-account sprawl. Agentic AI introduces another form of proliferation, but potentially at a much faster rate.
Gartner estimates that the average Fortune 500 enterprise could have more than 150,000 AI agents in use by 2028, compared with fewer than 15 in 2025. Gartner also reported that only 13% of organizations believe they currently have the appropriate AI-agent governance in place. These figures are forecasts and survey findings rather than a description of every enterprise, but they illustrate the scale of the management challenge emerging around autonomous software.
The problem begins with something deceptively basic: knowing what agents actually exist. An enterprise may have internally developed agents, agents embedded inside SaaS products, agents created by individual business teams and third-party agents connected through increasingly common AI tooling. If those agents are not discovered and catalogued, security teams cannot meaningfully determine what they can access or whether their permissions are still justified.
This makes agent inventory a foundational security capability. Before an organization can decide whether an agent should have access to customer records, financial information or internal documents, it first needs to know that the agent exists.
Every agent needs an owner
Traditional software can often be assigned to an application owner or technology team, but autonomous agents introduce a more direct question of accountability. Someone needs to be responsible for why the agent exists, what it is supposed to accomplish, which resources it can access and when it should be retired.
This is especially important because agents can outlive the project or employee that created them. An agent initially deployed to support a product launch might continue running after the launch ends. If nobody owns its lifecycle, its credentials and permissions can remain active long after its original business purpose has disappeared.
Microsoft’s current identity-governance approach for agents reflects this need for explicit sponsorship. Its documentation describes agent identities with human sponsors responsible for the agent’s purpose, lifecycle decisions and access reviews, alongside mechanisms for managing agent permissions and lifecycle events.
The underlying principle is familiar from conventional identity governance: an identity without accountable ownership eventually becomes difficult to control. The difference is that enterprises may soon need to apply that principle to software entities operating at a much larger scale.
Least privilege has to become more dynamic
The principle of least privilege is hardly new, but autonomous agents make it more difficult to implement using static permission models.
Consider an AI agent supporting procurement. It might need to retrieve supplier information, review purchasing history and prepare recommendations. Those capabilities do not automatically justify permission to create purchase orders, change supplier banking details or approve payments.
The challenge becomes even greater when an agent’s responsibilities change based on the task it receives. An agent may legitimately need access to one system for one workflow and a completely different resource for another. Giving it permanent access to everything it might eventually need would undermine the very principle of least privilege.
This is why the emerging agent-security architecture is moving toward task-scoped and context-aware authorization. The Blueprint Alliance, for example, advocates scoping access to the task rather than granting broad standing privilege, while also maintaining traceability when agents delegate work to other agents.
For SaaS platforms, this could become a significant architectural shift. Instead of simply asking whether an authenticated application has access to an API, enterprise systems increasingly need to understand what the agent is trying to accomplish and whether that action falls within its authorized scope.
Agent-to-agent delegation creates a new audit problem
The identity challenge becomes even more interesting when agents begin working together.
An employee could ask an enterprise agent to prepare a customer-renewal package. That agent might retrieve customer information from a CRM, ask another agent to check outstanding invoices, use a document agent to locate the existing contract and then request a pricing calculation from another system.
The resulting workflow could involve several autonomous entities, but the business action still originated with a human request.
Security teams therefore need to preserve the chain of authority throughout the workflow. An audit record that merely says “Agent C changed the customer record” is incomplete if Agent C was acting because Agent B delegated the task after receiving an instruction from an employee through Agent A.
The emerging model looks more like:
Human → Agent → Sub-agent → Tool → Action
Maintaining that chain matters for security investigations, compliance, accountability and incident response. It also becomes important when something goes wrong because organizations need to determine whether an action was malicious, incorrectly authorized, outside the agent’s intended scope or simply the result of a faulty workflow.
Authentication is only the beginning
Traditional identity systems have historically placed considerable emphasis on authentication: establishing that an entity is who it claims to be. Agentic systems require organizations to go further because a legitimate identity can still perform an unsafe action.
An agent may authenticate correctly and possess valid credentials, yet encounter manipulated information, an unexpected instruction or a workflow that causes it to operate outside its intended boundaries. In other words, valid identity does not automatically mean valid behavior.
This is why runtime monitoring is becoming an important part of the agent-security discussion. Gartner’s recent research argues that traditional written governance policies are insufficient for autonomous systems because policies alone cannot prevent an agent from taking a destructive action at machine speed.
The implication is that security controls increasingly need to operate during execution rather than only before execution. Organizations need visibility into agent behavior, the ability to detect anomalous activity and mechanisms for restricting or stopping an agent when its behavior crosses an established threshold.
The kill switch becomes part of enterprise architecture
The idea of an emergency stop mechanism may sound obvious, but autonomous software changes the urgency behind it.
A human employee who makes a mistake can generally be interrupted by another employee or administrator. An autonomous agent can potentially continue executing a multi-step workflow until a system blocks it, the workflow finishes or its credentials are revoked.
That makes rapid containment a fundamental design requirement. Security teams may need the ability to revoke an agent’s credentials, terminate active sessions, restrict specific tool calls or suspend an entire class of agents without dismantling the underlying business application.
This creates an interesting distinction between application availability and agent availability. An organization should ideally be able to stop a problematic agent without taking the CRM, ERP or collaboration platform it interacts with offline.
The ability to contain autonomous behavior therefore becomes part of resilience, not simply incident response.
SaaS vendors have an identity problem of their own
The agentic shift is not something that only security vendors and enterprise IT departments need to solve. SaaS companies themselves will need to rethink how their platforms expose data, functionality and permissions to autonomous software.
Traditional APIs were largely designed around applications making predictable requests. Agents introduce a richer context because the same API call could originate from different agents, represent different delegated tasks and require different levels of authorization.
SaaS vendors may therefore need to provide more granular controls around agent access, delegated authorization, auditability and runtime activity. Their platforms will increasingly need to understand not only which application is calling, but also which agent is acting and under whose authority.
This could become an important part of what makes enterprise SaaS “agent-ready.” A platform with excellent AI capabilities but weak identity boundaries could create more governance problems than business value, while a platform that exposes its data and workflows through secure, traceable agent interfaces could become a more valuable component of the enterprise agent stack.
Identity management is moving beyond humans and applications
The larger shift is that enterprise identity architecture is expanding beyond the categories it was originally designed to handle.
For years, organizations primarily managed people, applications and service accounts. AI agents introduce a fourth category: autonomous software entities capable of interpreting goals and taking actions across enterprise systems.
That means identity teams increasingly need to think about agent registration, sponsorship, permissions, delegation, lifecycle management, behavioral monitoring and containment as interconnected capabilities rather than separate security functions.
It also means the traditional distinction between identity and application security is beginning to blur. An agent’s identity determines what it can access, but its behavior determines whether that access is being used appropriately. The two problems increasingly need to be addressed together.
The enterprise security stack is becoming agent-aware
The arrival of dedicated agent-identity capabilities from major technology providers suggests that this is moving beyond an experimental security conversation. Microsoft now describes agent identity as a specialized identity construct, while the Blueprint Alliance is pushing a multi-vendor architecture built around discovery, identity, access control, delegation, monitoring and containment.
The important development is not simply that another security category is appearing. It is that autonomous software is forcing enterprises to reconsider assumptions that were previously taken for granted.
An identity used to represent a person or a predictable application. An agent can represent a business objective, operate across multiple systems and make decisions along the way. That makes its identity inseparable from its purpose, permissions and behavior.
Enterprise security therefore has to answer a more complex version of an old question. It is no longer enough to know who has access; organizations increasingly need to know which agent is acting, what it is trying to accomplish, what authorized it, what it can touch and whether it is behaving within those boundaries.
That may ultimately be the defining security challenge of the agentic SaaS era. AI agents could make enterprise software dramatically easier to use, but the less visible the underlying applications become to employees, the more important it becomes for security teams to maintain visibility into the autonomous systems operating behind them.
Key takeaways
- AI agents are emerging as a distinct enterprise identity category, rather than simply another type of application or service account.
- Agent sprawl could become a major governance problem as enterprises deploy agents across SaaS, data and infrastructure environments.
- Every production agent needs clear ownership, sponsorship and lifecycle management.
- Least privilege will increasingly need to be task- and context-aware, rather than based entirely on permanent permissions.
- Agent-to-agent workflows make delegation and end-to-end audit trails critical.
- Authentication alone is insufficient; enterprises need runtime visibility and behavioral controls.
- Rapid containment, including the ability to revoke or suspend agents, needs to be built into the architecture.
- SaaS vendors will increasingly need to make their APIs, permissions and workflows agent-aware and agent-governable.