Neha Duggal, Chief Product Officer at P0 Security: “Security teams need control at the point where an identity tries to take action”

As organisations race to embed AI into business processes, much of the conversation has focused on model performance, safety and governance. Yet a growing number of security leaders argue that the more pressing challenge lies elsewhere: controlling what AI agents are actually allowed to do once they are connected to enterprise systems. As autonomous agents gain the ability to access applications, trigger workflows and make decisions across multiple environments, traditional identity and access management models are being pushed beyond their original design.

For Neha Duggal, Chief Product Officer at P0 Security, the rise of agentic AI is creating a new category of identity risk that organisations are only beginning to understand. Drawing on extensive product leadership experience across cloud security and SaaS, including senior roles at Obsidian Security, Lacework and Elastic, she believes security teams must shift their focus from simply authenticating identities to continuously authorising actions in real time.

In this interview, Neha explains why AI agents represent a fundamentally different identity challenge from traditional machine accounts, how poorly governed automation can quickly translate into real-world business impact, and why the future of AI security will depend on runtime controls that keep authority scoped, temporary and accountable.

There’s growing discussion around agentic AI and autonomous systems in the enterprise. How is the identity and access challenge for AI agents fundamentally different from traditional machine or non-human identities?

AI agents are different because they are not just another machine identity doing a fixed job.

Most non-human identities are predictable. A service account, workload or API key is usually tied to a defined function. That does not make them safe, but it does make the control model more familiar.

Agents are more fluid. They interpret instructions, choose tools, invoke workflows and take action across systems. They may act through their own identity, through a service account or through permissions inherited from the human who invoked them.

That’s the real shift. The action isn’t coming from a human or an agent – it’s coming from both. Who asked, which agent acted, what tool it used, what it touched. That’s what we call blended identity, and it’s what your controls need to reason about in real time.

We’re hearing more about AI safety, but your team suggests the industry is now shifting toward operational control. What does that shift look like in practice for security teams?

AI safety used to focus mostly on what the model says: bias, hallucinations, prompt injection and data leakage.

Agentic AI changes the problem because agents do not just produce answers. They take action. They open tickets, change records, query databases, write to systems, trigger workflows and interact with sensitive applications.

That means security teams need to shift from monitoring AI behavior to controlling operational authority.

Authentication tells you who started the interaction. It does not tell you whether this specific agent should be allowed to take this specific action against this specific resource at this moment. That is the control gap. And it is where identity security must evolve.

In practice, that means enforcing policies at runtime, not just at login. It means scoping what an agent can do based on context: what task it was given, what it has already done, and whether the next action is within bounds. It means treating every tool call and every resource access as a decision point, not an assumption.”

Security teams that get this right aren’t slowing agents down. They’re the ones who can actually let agents run in production with confidence.

You mentioned in a recent statement that “the model may trigger the action, but the credential makes it possible.” Are organisations currently underestimating the identity risks associated with AI agents?

Yes. Most organizations still look at AI risk through the model. But the credential determines the blast radius.

A model can suggest an action. A token, service account or user credential makes that action executable.

The risk gets serious when agents are connected to email, files, ticketing systems, cloud consoles, databases or finance tools with broad, persistent permissions. If the agent makes a mistake, is manipulated or is compromised, it is still acting through valid access.

That is why least privilege is non-negotiable for agents. Agents often sit between humans, systems and non-human identities. They can inherit authority from all of them. If any part of that chain is over-permissioned, the agent can move quickly with access it should never have had.

Over the past year, what kinds of public security incidents have most clearly demonstrated the dangers of poorly governed AI-driven automation?

The clearest pattern is not that every incident involves a malicious agent. It is that autonomous systems can move from a bad instruction or flawed decision to real business impact very quickly when they have standing access.

Replit is a good example. Its AI coding agent reportedly deleted a live database during a code freeze, despite instructions not to make changes. PocketOS is another. Reporting says a Cursor agent deleted production data and backups after using overly broad access through an API call.

Composio shows the infrastructure side of the problem. The company disclosed a May 2026 incident involving internal systems connected to its agentic infrastructure. Security analysis later described the exposure of thousands of API keys and GitHub OAuth tokens.

The lesson is the same across these failures: the business impact comes from a lack of runtime authorization. AI-driven automation compresses the time between a mistaken action, compromised workflow or abused credential and a real consequence in production.

As enterprises adopt more AI-powered workflows, how should identity security evolve to prevent automation from becoming a business risk?

Identity security must move from static access to continuous authorization.

For agentic workflows, every meaningful action should be treated as its own authorization decision. Policy needs to evaluate the invoking user, the agent, the tool, the target resource, the requested action and the business context together. That is how you move from “this identity has access” to “this action is allowed right now.”

Access should be just enough, just in time and removed when the task is complete.

The audit trail also must change. It cannot simply say “the agent did it.” It needs to show who delegated the task, which agent acted, what tool was used, what data was accessed and why access was allowed or denied.

You’ve held product leadership roles at companies including Obsidian Security, Lacework, and Elastic. How has the cloud security conversation changed over the past five years, particularly with the rise of AI?

It feels like déjà vu. Five years ago, companies were racing into cloud. The business wanted speed. Security teams were asked to catch up. A lot of organizations moved first and figured out the control model later.

We are seeing the same pattern with AI at turbo-speed. Companies are integrating AI into workflows as fast as they can, but the governance model is still catching up.

The big change is identity sprawl. It is no longer just employees and admins touching sensitive systems. It is service accounts, API keys, CI/CD workflows, SaaS integrations, workloads and now agents.

The environment has become much more dynamic, but many access models are still static. AI makes that gap harder to ignore because agents can act continuously across systems. Visibility helps, but it is not enough. Security teams need control at the point where an identity tries to take action.

Many organisations are rushing to deploy AI internally. What are the most common governance or access-control mistakes you’re seeing companies make today?

The most common mistake is giving agents broad, standing access because it is the fastest way to get the workflow working.

Teams connect an agent to a user credential or service account, prove the use case works and then move it into broader use without revisiting the permission model.

The second mistake is treating agent governance as an inventory problem only. Inventory matters. But knowing an agent exists does not reduce risk if it can still reach sensitive systems with excessive authority.

The third mistake is losing attribution. If an agent calls another agent, invokes a tool or uses a shared credential, the original user and business context can disappear. That becomes a real problem when something goes wrong, and the audit trail cannot explain who authorized what.

Looking ahead, what will separate organisations that successfully operationalise AI securely from those that struggle with control, visibility and trust?

The organizations that succeed will be the ones that realize AI security is not only about model quality. It is about authority.

They will understand who can delegate work to an agent, what that agent is allowed to do, which systems it can touch and when access should be blocked, limited or escalated.

They will also prioritize runtime control over after-the-fact review. Policy has to be evaluated when the agent tries to act, not weeks later in an access review or after an incident.

The organizations that struggle will rely on broad credentials, manual approvals, incomplete inventories and audit trails that cannot explain what happened.

AI will move faster than those processes. The winners will be the companies that let the business adopt AI while keeping authority scoped, temporary and accountable.