OpenAI’s Fotis Chantzis on why identity protocols weren’t designed for agents

Zero-Shot Learning is a podcast for AI builders, hosted by Nancy Wang, Chief Technology Officer at 1Password, and Dev Tagare, Senior Director and Head of Engineering for Gemini Enterprise & Business at Google. Together, they’ve built and scaled AI systems at the infrastructure and product layers and bring a builder's perspective to every conversation. The name, zero-shot learning, is an AI concept about applying existing knowledge to new tasks without specific training. For this show, it’s also the premise. Each episode features in-depth discussions with the people building today’s most advanced AI systems, unpacking how agentic architectures are designed, and how teams handle the realities of shipping systems into production. Authentication is built on the assumption that identity can be verified once and trusted for a specified period. Over time, the security industry has gotten very good at validating that trust through a chain of identity providers, certificates, and infrastructure that confirm that a user is who it claims to be at login. Authentication assumes that identity and intent will stay relatively stable and predictable because it was designed for people whose behavior is largely stable and predictable. Agents break that assumption entirely. They act non-deterministically, starting with one task and expanding their scope as they work, accessing new files and APIs, making their identities difficult to track. When an agent acts autonomously on a person's behalf, the question is no longer whether it can log in; it's how it uses access after it does. To establish a control plane for agents, Nancy asks, “If you’re a CTO and you’ve been told to deploy internal agents into production, what are the no-excuses minimum controls for identity, authorization, secrets handling, and audit? Fotis Chantzis, Agent Security Lead at OpenAI, joined Zero-Shot Learning, 1Password’s AI builder podcast, to talk through why the protocols built for human identity don’t hold up under those conditions, and what teams can do to secure agents in production. Static authorization fails when agents get new ideas Continuous authorization is the practice of evaluating and enforcing access permissions at each step of an agent's workflow, rather than granting access once at the start of a session. OAuth and OIDC assume relatively stable scopes and front-loaded authorization decisions. A user signs in, approves access once, and the system moves forward with that grant. But agents make decisions and take actions beyond the original intent of the person who authorized them. As Fotis says, "There is no concept of continuous authorization that agents require because an agent starts with one task and then decides that it needs to do something else." For example, a coding agent might start by accessing local files, then decide mid-task that it needs to browse the web for API documentation. At that point, it writes a new task and downloads the documentation file. Nothing was re-evaluated to determine whether that change should be allowed. An agent can take dozens of these actions in seconds, adding new tools and risk with each move. A functional identity model for agents must continuously evaluate access as the workflow evolves. Otherwise, teams face the familiar tradeoff of blocking too much and slowing work, or approving too much and holding their breath. At 1Password, we see the value in continuous, workflow-aware authorization, where access is brokered at runtime, scoped to each action, and enforced at each step through a control layer that mediates how credentials are used. Nancy framed this as a question of how authority moves between users, agents, and tools: “This brings us to the concept of delegation chains and how we should think about them, scope, duration, thresholds, and the systems those agents are allowed to access.” Attribution has to survive across tools, runtimes, and sessions Attribution is the ability to trace every action an agent takes back to the human who initiated it and the authority under which it ran, across every system the agent touches. Nancy framed the operational challenge directly asking, when an enterprise needs to investigate an incident or audit access, how does it determine which agent actually accessed a system or dataset, and under whose authority? For agents, attribution breaks as work moves between systems because each step is recorded separately, severing the connection to the original user or task. Without attribution, we lose governance.” –Fotis Chantzis, Agent Security Lead, OpenAI In an incident response scenario, teams work backward from logs to reconstruct what happened. With agents, that quickly becomes difficult. The agent may start in one environment, then call multiple systems, each logging events separately and without shared context. In one system, the action might appear under a user identity. In another, it shows up as a service account. In a third, it’s tied to an API token.

Excerpt shown under the publisher's RSS terms · 115 words · full text and figures are on the publisher's site