Presented by Ping Identity

---

Enterprises need to treat zero trust security architecture as an immediate requirement for AI agents rather than a long-term goal, says Andre Durand, CEO and founder of Ping Identity. Zero trust, the security model built on the assumption that no user, device, or system should be automatically trusted, requires continuous verification before every action rather than a single check at login. Agentic AI has profoundly compressed the risk timeline enterprises must manage, demanding that permission decisions be evaluated in real time.

type: embedded-entry-inline id: 1Ieiy1KhHNWZE5KVqNdA1G

That compression shows up in how permissions accumulate. Every time an employee approves an AI agent’s request for access to a company drive, a database, or a code repository, the enterprise hands over a sliver of control that looks routine in isolation. Across thousands of agents making thousands of requests, those approvals accumulate into an exposure that most existing security architectures were never built to measure.

“The rise in desire to use agents right now, and the speed of agentic, is highlighting the need to move faster on the principles of zero trust,” Durand says. “Agents just move faster, full stop. A human compromise might be measured in minutes or hours, sometimes days. At agentic speed, a thousand actions could happen in five minutes.”

Why zero trust is now urgent for agentic AI

That difference in velocity changes how enterprises need to think about permissions. Two variables matter: the surface area of access an agent is granted and the duration that access remains valid. Traditional identity and access management tends to grant broad permissions and leave sessions open for extended periods because the human using them moves at human speed. Zero trust, in contrast, collapses both variables at once by narrowing access down to what is strictly necessary and revalidating it continuously, rather than once at login.

“Zero trust really just says, just enough, just in time,” Durand says. “It’s your next action that we care about. We’re moving identity from an era where access was our runtime control point — meaning were you logged in, did you have a session — toward the decision that sits behind that login.”

Why agents must be treated as first-class identities

That shift to decision-based control has direct implications for how agents should be provisioned in the first place. The common practice of letting an agent operate under a cloned human login or a shared service account doesn’t work, Durand says.

“Each agent should have its own identity,” he explains. “It should not be impersonating the human. It can act on behalf of the human, we could explicitly delegate authority to an agent, but we don’t want to blur the lines between the human taking action and the agent taking action.”

And beyond that is another concern: the shared secrets, API keys in particular, that many service accounts still rely on. For example, the habit of embedding keys directly in source code, where they can be committed accidentally and exposed, is a convenient but weak security pattern that agentic workflows make considerably riskier. Building service account architectures that let agents authenticate without relying on those shared credentials or other long-lived standing access is now an urgent priority rather than a long-term cleanup project.

Where enterprises can enforce zero trust policies

Enforcing any of this in practice requires identifying where policy can actually be applied. Several existing choke points, including API gateways and the agent gateway sitting in front of MCP servers, offer practical locations where enterprises can inspect what an agent is requesting and apply policy rules before granting it.

“Those policies could leverage real-time risk and fraud signals, and then enforce, deterministically, what the agent can do when it interacts with these systems,” Durand explains.

The goal is to move authorization from something decided once at login to something evaluated at the moment of every consequential action, such as an agent attempting to commit code to a repository. Instead of carrying a standing permission to write to GitHub, the agent’s request would be checked against context and policy at that specific moment, closing the window of trust down to the scope of a single action.

Stopping AI agents from rewriting their own permissions

That model becomes especially important given how agents can behave once they are already inside a system — for example, coding agents that have acknowledged, when questioned, either ignoring a specific guardrail entirely, or attempting to rewrite the permissions they were given.

“Who’s watching the watcher? Zero trust needs to apply here,” Durand says. “If generative AI systems follow your instruction 97% of the time, and you’re simply asking it for advice, that might be fine. If it’s responsible for making a decision about who gets let in, 97% is not good enough.”

How to trust AI-generated output at agent speed

The answer to that gap is not to eliminate AI from the review process, but to structure reviews so no single agent’s judgment is taken at face value. Because human review cannot scale to the volume and speed of agentic output without erasing the advantage of using agents at all, a new framework is necessary, so that when one agent produces work, such as code, separate agents evaluate it, provided those reviewing agents are kept from communicating with one another or with the one they are checking. It’s a new human-AI paradigm, Durand says.

“We probably will have to develop frameworks that we trust without seeing or verifying the output directly,” he explains. “It’s not that that construct is 100% foolproof. However, it’s the best we can do to move at agent speed. We can’t trust the exact output, but we can trust the framework.”

In practice, that means combining automated review with clear human accountability for higher-risk decisions, rather than treating agent output as self-validating.

For traditional auditors, reviewing every transaction individually is never feasible, and statistically valid sampling stands in for full verification. The same applies to risk accumulation: a single agent action might carry little risk on its own, while a sequence of actions moving in a consistent direction could cross a threshold that triggers an intervention, including a kill switch capable of halting the agent before further harm occurs.

What to ask when evaluating agentic identity platforms

For security leaders evaluating identity platforms for agentic AI, there’s no narrow checklist. Enterprises should evaluate what their full lifecycle of agent management looks like. Most enterprises are managing agents on two fronts simultaneously: customer-facing agents acting on behalf of external users, and internal agents deployed to automate enterprise processes.

“Pause long enough to see the totality of what it would mean to secure multiple agents, both interacting with you from the outside as well as being deployed on the inside,” Durand says. “We need discovery and visibility of all the agents operating within our estate, a place to register them, a standard way to assign custodians, and a way to construct and centralize policy so security can enforce it across the organization.”

And while basic security principles were already fully understood before agentic AI arrived, what has changed, Durand says, is that the cost of moving slowly has finally caught up with the cost of moving carelessly, giving enterprises a narrowing window to build the right architecture before widespread agentic adoption makes retrofitting far more expensive.

---

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

Security | VentureBeat – ​Read More