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

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. Each step appears valid on its own, but the connection between them isn’t preserved.

Investigators can see the individual steps, but not the full chain of actions or who was responsible for them.

Nancy connected this to a growing need for execution traces that can compare an agent’s intended plan with what it actually did, step by step, across prompts, tool calls, and outputs. For auditing, this proves that the agent operated within the bounds of what it was supposed to do.

A stronger approach preserves attribution at each step, so every action can be traced back to its initiator and the authority under which it was performed. 

That shift from reconstructing activity to proving it changes what’s possible in audit and in policy enforcement.

Authority has to be mediated

Mediated credential use means routing an agent's access through a controlled layer (a proxy, gateway, or injection layer) that binds credentials to specific destinations, rather than passing the underlying secret to the agent directly.

The most immediate risk from continuous agent action is how the systems handle credentials.

It's essentially game over if a credential ends up in the context window of the agent."

–Fotis Chantzis, Agent Security Lead, OpenAI

Once a secret is exposed to the model, it introduces the risk of credential exposure, whether through a prompt-injection attack or other, less malicious means. Handing an agent a credential isn't effective delegation.

The alternative is to mediate access rather than hand it over. Systems can route access through controlled infrastructure, such as proxies, gateways, or injection layers, that bind credentials to specific destinations and enforce their use. The agent can request access, but never holds the underlying secret. A compromised agent may still attempt unintended actions, but has far less freedom to abuse the authority granted to it.

The minimum control plane before deploying to production

In the episode, the hosts agreed that the control plane, the system that enforces how access is used across identities, tools, and actions, has to persist as agents act, across systems, over time, and through changing intent.

The baseline looks different from human access controls:

• Credentials have to be short-lived and scoped to the task, not granted broadly and reused

• Execution has to be constrained by the environment, not assumed to behave

• Secrets can’t be exposed to the model; they have to be mediated at the point of use

• Every action has to be attributable back to both the agent and the human who delegated it

• Policy has to be enforced continuously, so intent drift is detected before it becomes an incident

Authentication still matters, but it can’t carry the full load. Identity tells you who delegates an agent; it doesn’t control what happens next.

Teams can't wait for standards to catch up

But IT teams don’t have the luxury of waiting. Agents are already operating in production.

Agentic security is still a moving target. To secure agents today, teams need continuous authorization, attribution, and mediated access. The standards agents will rely on around identity, delegation, and authorization are still evolving. Extensions to OIDC, verifiable credentials, and cross-provider delegation models are in development but not yet ready.

In the meantime, most teams aren’t waiting for a perfect model. They’re adapting existing controls, tightening credential lifetimes, introducing mediation layers, and treating agents as first-class machine identities with explicit boundaries.