Why AI Agents Need Their Own Identity: Lessons from 2025 and Resolutions for 2026
- Ayesha Dissanayaka
- Associate Director/Architect , WSO2
As we close out 2025, it's time to reflect on the hard lessons learned from deploying AI agents in production environments. The promise of AI agents is compelling: autonomous systems that can handle complex tasks, make intelligent decisions, and execute actions on our behalf. But as several high-profile incidents this year have starkly demonstrated, this autonomy comes with unprecedented risks when proper identity and access management controls are absent.
As organizations plan their 2026 AI strategies, there's one resolution that should top every security team's list: treating AI agent identity and access management with the seriousness it deserves. The cautionary tales from 2025 provide the perfect roadmap for what not to repeat in the new year.
When agents go rogue: 2025's wake-up calls
Two recent high-profile incidents serve as cautionary tales for the agentic AI era. In the first, Google's Antigravity agent deleted the entire contents of a user's drive: not a specific project folder as intended, but everything. The agent later acknowledged this was not within its scope and represented a critical failure on its part. In the second incident, a Replit agent went rogue during a code freeze, deleting an entire production database despite explicit instructions stating "NO MORE CHANGES without explicit permission."
Both agents, when confronted, admitted their mistakes. Both operated outside their intended scope. Yet the damage was already done: irreversible in some cases, catastrophic in others.
The borrowed credentials problem
The root cause in both scenarios points to a fundamental security gap in how we currently deploy AI agents. Users naturally tend to give agents access by borrowing their own credentials. It's convenient, familiar, and often feels like the only practical option. After all, this is how we've historically worked with software systems—our applications act as extensions of ourselves, operating under our permissions.
But AI agents are fundamentally different from traditional software. Unlike a deterministic application that follows predefined logic paths, agents can reason, interpret context, and take dynamic actions. They make autonomous decisions based on their understanding of natural language instructions and environmental context. This autonomy, while powerful, introduces a new class of risks when combined with unrestricted access.
Consider the Antigravity incident: instead of executing a delete command from the temporary folder as likely intended, the agent executed it from the root directory. A simple targeting error, perhaps, but one with devastating consequences. Now imagine your finance assistant agent making a similar mistake: deleting a year's worth of financial records instead of a single duplicate file. Or consider a seemingly minor numerical error: processing a purchase order for $9,999 instead of $99.99. For an autonomous agent with write access to financial systems, such mistakes aren't just possible; they're inevitable given enough operational time.
Why traditional IAM doesn't work for agents
Traditional identity and access management systems were designed for two types of actors: human users and service accounts. Human users have context, judgment, and accountability. Service accounts represent well-defined applications with predictable behavior patterns. AI agents fit neither category cleanly.
When an agent operates using borrowed user credentials, several critical problems emerge:
Loss of Attribution: When an agent acts using your credentials, system logs show you performing those actions. If something goes wrong, there's no way to distinguish between actions you took directly and actions the agent took autonomously. This makes forensic analysis, compliance auditing, and incident response nearly impossible.
Excessive privilege: Users often have broad permissions accumulated over years of work. An agent inheriting these permissions gains access far beyond what it needs for its specific task. This violates the principle of least privilege, a cornerstone of security architecture.
No scope boundaries: Without distinct agent identities, there's no way to enforce that a data analysis agent should only have read access, while a deployment agent might need write permissions to specific systems. Every agent gets the same access as the user, regardless of its intended function.
Accountability gaps: When something goes wrong, who is responsible? The user who granted access? The agent that made the decision? The system that allowed the action? Without clear identity boundaries, accountability becomes murky, a serious problem for both internal governance and regulatory compliance.
The case for agent-first identity
AI agents need to be recognized as first-class identity principals: distinct entities with their own credentials, permissions, and audit trails. This approach, which WSO2 calls an "agent-first identity model," treats agents as separate actors in the system, subject to the same rigorous governance we apply to human users.
Administration: Just as organizations provision and manage human user accounts throughout their lifecycle, agents need dedicated identity management. Each agent should be registered with clear metadata about its purpose, capabilities, and operational boundaries. This enables centralized visibility into the agent population and consistent enforcement of governance policies.
Authentication: Agents require authentication mechanisms suited to their nature: machine-friendly credentials like mutual TLS or private key JWT that can be managed programmatically and rotated automatically. Strong authentication ensures that when an agent claims to be "FinanceAnalysisBot," it actually is that specific agent and not a compromised impostor.
Authorization: This is where the real power of agent identity emerges. With distinct identities, organizations can implement fine-grained, context-aware access control. A data analysis agent receives read-only permissions. A financial transaction agent operates with highly restricted and monitored access to payment systems. A deployment agent has write access only to development environments, not production. Authorization policies can consider not just what the agent is requesting, but who delegated permission to the agent and on whose behalf it's acting.
Audit: When agents have their own identities, every action they take is logged with full context: which agent, what action, on whose behalf, and under what authorization. This independent audit trail is fundamental for security investigations, compliance reporting, and continuous improvement of agent governance policies.
Building trust through governance: Your 2026 resolution
The incidents with Antigravity and Replit aren't arguments against AI agents; they're arguments for treating agent security with the seriousness it deserves. As enterprises deploy agents to handle increasingly critical tasks, proper identity and access management becomes not just a best practice but a business imperative.
“Make this your 2026 resolution: implement proper IAM for every AI agent before it touches production systems.”
Imagine if the Antigravity agent had been operating with its own identity, granted only permission to delete files within the specific project directory. The mistake might still have occurred, but the blast radius would have been contained. System permissions would have prevented the catastrophic loss. Similarly, if the Replit agent had distinct credentials with read-only access during the code freeze period, it would have been unable to delete the production database regardless of its reasoning process.
The path forward: Starting 2026 right
The agentic AI revolution accelerated dramatically in 2025, transforming how organizations operate. But as the year's incidents demonstrated, without proper identity and access management foundations, we're essentially giving autonomous systems the keys to the kingdom with no ability to audit their actions or limit their reach. The convenience of borrowed credentials creates a false sense of control while introducing systemic risks that will only grow as agent deployments scale in 2026.
The solution isn't to slow down AI agent adoption; it's to build it on the right foundation from the start. Make 2026 the year you get agent security right. By treating agents as first-class identities with their own lifecycle management, authentication mechanisms, authorization policies, and audit trails, enterprises can deploy AI agents confidently, knowing they have visibility, control, and accountability.
The question isn't whether agents will make mistakes; they will. The question is whether we'll have the controls in place to prevent those mistakes from becoming disasters.
Ready to secure your AI agents? Start 2026 on the right foot by experiencing WSO2 Agent ID capabilities firsthand with Asgardeo, our cloud-native identity platform. Try out agent identity management, authentication, and authorization in a live environment. Get started with Asgardeo and see how enterprise-grade IAM can protect your agentic AI deployments.