When Good Creds Go Bad: The New Failure Mode of AI Agents

Summary

This video explores how authenticated AI agents can use valid credentials to perform policy-compliant but semantically incorrect actions—such as granting overly permissive access—that only surface in audit logs after the fact.
The solution requires moving beyond static identity checks to contextual authorization, just-in-time credential access, and intent binding that ties an agent's original purpose to each downstream OAuth delegation throughout the workflow.
Presenters from 1Password and Asana argue this is a cross-company problem: no single vendor can currently ensure that agent intent persists without drifting across all authorization layers in a distributed agentic system.

When Good Creds Go Bad: The New Failure Mode of AI Agents

Authenticated AI agents introduce a new failure mode. Using valid credentials, they can perform actions that are policy-compliant but semantically incorrect, such as retrieving sensitive data into the wrong context or executing unintended changes. Traditional IAM systems evaluate identity and permissions, not intent or correctness at runtime. As agents begin using valid credentials to act across enterprise systems, security teams must move beyond static identity and permission checks. this video explores contextual authorization, just-in-time access, and runtime auditability as the next layer of enterprise agent security, including what it means to verify not just who an agent is, but whether the environment it’s running in can be trusted.
Talk By: Jeff Malnick, VP, GM of Developer and AI, 1Password ; Nancy Wang ;

Chapters

FAQs

What is the new credential failure mode introduced by authenticated AI agents?

Traditional IAM systems evaluate identity and permissions but not intent or correctness at runtime, so an agent can make calls that are technically authorized but semantically wrong—for example, granting external partners overly permissive access to Databricks clusters. This failure only becomes visible when audit logs are reviewed after the fact.

What is intent binding and why is it important for agent security?

Intent binding ties the original stated purpose of an agent to its identity before any downstream calls are made, so every action in the sequence can be checked against that original intent. Without intent binding, the agent's purpose can drift across authorization layers, leading to actions that no individual system flagged as invalid but that collectively produce an unintended outcome.

How does just-in-time access improve security for AI agents?

Just-in-time access ensures that an agent receives credentials only for the specific task it is currently performing, rather than holding persistent or reusable tokens across multiple tasks. This limits the blast radius if an agent is compromised or acts outside its intended scope, because its credentials expire or are scoped to a single operation.

Why does solving this AI agent security problem require collaboration across multiple companies?

As described in this video, the challenge of ensuring intent persists across all authorization layers in an agentic workflow spans the agent itself, the credential broker (such as 1Password), the data platform (such as Databricks), and the application layer (such as Asana). No single company controls all these layers, so the solution requires cross-vendor coordination on contextual authorization standards.

Full transcript

[00:10] Okay, so we are the after lunch crew. Uh, my name is Nancy Wang. I'm the CTO at 1Password. >> Everyone, I'm Jeff Melnick. I'm the head of developer and AI at 1Password. >> And I'm Amritansh. I'm the CTO at Asana. >> Yeah, so today we're, you know, together
[00:24] to talk about when good creds go bad. Uh, aside from obviously being a very cheeky headline, uh, this is becoming a real problem, especially as more enterprises, you know, take advantage of
[00:36] what agents can bring, right? Take it into production, and this walks you through a use case of how good intentions, right, can actually lead to misaligned results. And so,
[00:49] today each of us is going to go through, you know, part of this presentation. So, to start off here, right, this is, uh, something that Jeff loves dearly, which is a sequence diagram. Right, and each of the entities here in
[01:02] this sequence diagram, going all the way from the user to the agent, to, for example, the Databricks MPC P server, to 1Password as the broker of access, all
[01:14] the way to the data plane, right, the data layer, uh, where sensitive data is stored. You know, each of these calls actually works as intended, right? Down to, for example, 1Password actually
[01:26] issuing the scoped, uh, PAT to uh, the agent to be able to do what it needs to do within Databricks, right? But actually, after the fact, you notice, "Hey, there were actually things
[01:38] that happened, you know, maybe external partners actually got over-permissive grants to go do things within Databricks clusters. How did that actually happen?" Well, if we actually walk through the audit logs, how it happened, right, was
[01:52] actually, if you notice here, in the tool description, you had an extra grant. But you didn't actually find out that you did until you looked at the audit logs afterwards. And so, this is why making sure that the intent of the
[02:05] agent before this whole sequence even starts is actually bound to the agent identity such that as each of these calls are making or are happening in real time, you can actually make sure that hey, this call right down to this
[02:19] issue token still maps to what was the original intent of that agent. So, why are we all here together, right? Three of us. And why we're here together
[02:31] is actually this is a cross-company problem, right? There's not actually a single company today that can solve essentially the making sure the intent persists across all of these layers in a way that it doesn't drift, right? Making
[02:44] sure that data access patterns actually happen as intended. And that is why if we go from, you know, one to two to three, right? You need folks who understand how credentials are issued, right? How you authenticate identities.
[02:57] Two, for example, the agent which my colleague here Matan will talk about in a moment, right? Which is how do you digital AI teammates actually make tool calls, right? Because they're productive, because they can do things
[03:09] with your systems, enact very complex workflows. And then finally, you know, our partners here at Databricks allow us to actually go inside the sensitive data, you know, stack and be able to make edits, be able to, for example,
[03:22] port queries from that data. And so, this is where for example, you know, this token isn't just an identity. And so, if you think about, for example, you know, why we've
[03:34] been talking about, you know, here at 1Password, each agent needs their own identity, right? Because sometimes it is bound to the human, right? But, do you really want, for example, your human identity to be associated with, for example,
[03:46] things that the agent is doing? No, because we want the ability to actually differentiate between the agent and the human. And this leads us to number two, right? And this uh concept about compound identities, which Jeff will go
[03:59] into more detail in just a second, is super important because you need to know that it's not just Jeff acting, but actually it's Jeff and Jeff's agent, right? And what he enabled this agent to do. And then going back to, you know, just
[04:12] enough, just in time, right? And this goes back to, you know, how breaches are happening now, which is, "Hey, you hand your agent the keys to the kingdom and it just continues doing the same, for example, over-permissive actions again
[04:25] and again." Maybe it's not sends uh, you know, cash transactions to the wrong account over and over again. That That would be pretty catastrophic. And so that is why, you know, our security
[04:37] principles are we give credentials, right? Or access, rather, just in time. And there's also a concept of just enough, right? You don't want to give access to the entire database. Maybe just a simple, you know, a few rows that
[04:49] actually need to be updated. And then finally, this is probably the most important part, right? Is you want to be able to chain that uh those series of actions that the agent is taking all the way back to the human.
[05:02] So with that said, let's uh take a deeper look at identity. >> Awesome. Thanks, Nancy. So as Nancy just pointed out, the the original sequence that we had here, and I'm just going to go back to it briefly,
[05:14] everything that happened in this flow was completely valid. And the thing that we'd like everybody to walk away from this talk with today is that even when everything goes right, things bad things can still happen. And prompt injection
[05:26] is a really challenging thing for us to go and solve. We're not here to deliver a panacea for solving prompt injection. At the end of the day, as security professionals, our job is to minimize the blast radius and just assume that everything has already
[05:38] been injected with bad prompts. The thing that we're that we want to talk about in depth is that the the set of protocols and the current way of thinking about security just isn't enough anymore, right? Even if you have
[05:50] the best hygiene, even if you're doing all the right things, bad things can still happen. Prompt injection still has a massive blast radius for your organization. The way that we are thinking about this at 1Password is by thinking through
[06:05] all the different actors in the system. So, today, an access token, we noted earlier, doesn't actually carry any identity information, not all the time. There's different tokens actually carry that type of information, bind it to an
[06:18] an actor in the system. The way that we think about a giving delegating to an agent today is through traditional delegation workflows, which give the agent access to that system,
[06:31] but it doesn't carry the intent of the human actor through to the action that the agent actually takes. The outcome of this is that the agent can end up doing more things in that system than you asked it to. It can do it multiple times
[06:43] in a row. It's not bound to a specific action for a specific period of time, and for a a limited number of actions. Today, when we're looking at all the different protocols that are out there,
[06:56] we have six different buckets that we can kind of throw this into, where things start to fall apart. The first thing, and I'll come back to this later, is that the agent gets tricked by the text it reads, right? That's the prompt injection. This is a pretty doesn't need an introduction to
[07:09] this room. You can't avoid prompt injections. I think that that's something that's uh you know, you can do your best to protect yourself against it, and you should, but at the end of the day, agents are reading context from so many
[07:21] different places that it's next to impossible to solve for that alone. So, you have to come up with a way to limit the blast radius. Every time an agent gets
[07:33] the current OAuth spec that we have today, it gets a different identity depending on the authorization server that it's talking to. So, if an if a human delegates an agent to go do something in G Suite and then does that again for
[07:46] something in Slack, those different authorization servers are going to write a different subject header if that agent didn't arrive there with an actual identity token in the first place. And so, delegation alone isn't going to solve this problem. It creates a huge
[07:58] problem for our security teams and our CISO organizations because those teams are responsible for taking all of these disparate logging systems, pulling them together in a lake house somewhere, and then providing their security teams with
[08:10] access to that data. But, if the agent is showing up as a different actor in all of those different systems, it's going to be impossible for those teams to actually pull things together. This is another one that I may come back to later, which is that the token can do
[08:23] way more than what was originally intended. So, when you do a delegation flow in traditional OAuth, you end up with a situation where you're actually granting long-time access to that agent for a given system.
[08:35] That agent can act with that token over and over and over again. That's a problem that we need to go and solve. The These are of core issues that we need to go solve as a community. And
[08:47] there's We're going to talk about this a little bit more later, but 1Password as the issuer of the credential and the issuer of the identity, Asana as the agent runtime, Data Data Bricks as the the the place
[08:59] where the agents actually gain access to, all of us have to kind of come to this from the perspective of it's going to take a community to go solve these things. Everybody's going to be responsible for a different part of the stack.
[09:15] So, this is something that emerging protocols today actually can give us a view into what how we're going to solve these gaps in the future. So, today a user signs in somewhere, they get an identity token, they go and
[09:28] delegate that access using that identity token to a to an agent, and that agent then gets a long-term access token. They can go refresh that token. It you know, depending on the way that the delegation workflow took place,
[09:41] at the end of the day, that agent can reuse that token over and over and over again. There's different specs today that are emerging. One of those is transaction tokens that allow you to actually provide a token to an agent for a very
[09:53] specific tasks task that can only be used once. This is a great example of just enough access just in time and tightly bound to a very very short period of time. Transaction tokens I
[10:06] think carry like a 1-minute TTL. That sort of thinking around how we want to go give access to agents is what we need across the security spectrum for us to really solve this problem. The intention in a transaction token is
[10:19] carried through with the what is essentially a version of rich authorization. And that RAR spec inside of that transaction token can actually give the agent a very very specific
[10:32] action they can take. A very specific uh you know, read query on a database for specific row in a table. And by constraining it to that point and to only be able to use that token once, the resource server that's making the
[10:45] policy decision can be much more nuanced and specific about how it's going to go about uh providing access to that agent, what that agent can do in that system. Our existing specs that we have today
[10:57] don't carry this type of information, this sort of rich information that's going to allow our policy uh the policy decision points, the resource servers for from making the correct decision.
[11:09] >>
[11:22] And we in the tools that we are building and the security solutions that we are building, that is a principle that I don't think we need to back away from. And I think that the community by and large has actually come to the same
[11:34] agreement on this. It's I don't think it's controversial today to say that an agent should not receive a credential to anything, no matter how tightly scoped. As a community though, we need to come together and actually decide on which
[11:47] protocols we're going to be choosing to go and solve these solutions. And together we can create a world where those things interoperate in a much more secure fashion. As the credential provider, we know that the upstream resource server that that
[12:00] credential might be for can go and make the right policy decision. And that when it's making that policy decision, when it actually gets the data, it's only going to be able to do that for a very limited amount of time. And the data that we need to go and audit as a
[12:12] security organization, as an IT team, we can we have that data in spades and we can make really good comprehensive decisions and do good retrospectives on what occurred at any given point in time.
[12:27] With that, I'm going to pass it off to Armitash. >> Thank you, Jeff. >> Thank you, Jeff. >> Um so as I mentioned, I'm from Asana. And about two years ago, we started building agents into Asana, what we call AI teammates. And you know,
[12:41] we talked about a lot of the security problems that you're hearing about today. Um And as we zoomed out, we knew we had to go figure this from scratch. And really the the reason was that it was clear to us
[12:55] that the context that we were building these agents in has changed, right? Like so as engineers, when you think about context, you think about like what are the protocols, what's the architecture, you know, what are the layers that you have. What we forget is sort of like the air
[13:07] all around us. Actually, everything that we've built, we have built around a social construct. Um you might have heard this analogy that you can think of a agent or a teammate as a fresh graduate or as an intern.
[13:21] And that analogy only goes so far because even when you have employees in your company and they were humans, there was a social contract around them or as I joke like "Don't do this unless you want to get fired." And people sort of understood
[13:33] that and that's not something that agents understand. So, going back to first principles and saying given that that social construct doesn't exist, how should we go and design the system? Here are some principles we came up with, right? The first was the agent has
[13:47] to be a distinct actor. It's distinct actor from apps, it's not the same thing as an app where you can actually sort of do static analysis and you can understand what the code does, right? It's not the same thing as a workload or a service, it's definitely not the same
[14:00] thing as a user or a human, right? Uh so, we have to make sure that we've thought through identity and access control from that perspective. Uh Jeff mentioned this already. OAuth scopes and grants were again for
[14:14] that social construct where people sort of expressed intent and pretty much followed through on that intent. Um but now we have to go change that. We wanted to make sure that we have much tighter much tighter scopes, scopes that
[14:27] were down to a single transaction. Um and the last principle for us was to ensure that there was attribution. Look, in the end something will go wrong somewhere and you have to be able to follow the chain of events that caused
[14:40] that. So, this is not just about what was the agent that did that, it isn't even about like who created that agent, but everything from the creator of the agent, the person that initiated the execution, and all the other people who
[14:53] might have been on the loop or other agents that might have been in the path of that action taking. You have to build a chain of attribution if you are to go and debug this in case a security incident happens. So, those are the principles that we used in
[15:06] order to build Asana and when we think of Asana, we think of it as this control plane for orchestrating agents. The tagline we'll often use is that it's the operating system for humans and agents teams, right? And the way it manifests for us
[15:20] is that we make sure that the human is in the loop. Asana is built to make sure that it is a multi-party experience. That humans and agents share a single plan. If there's a sensitive action, you
[15:32] can get explicit approval for this. Just built into the user experience that we have. So that you have people who signed off, which then goes and helps you with that attribution chain, right? The second thing that we said is that we
[15:44] want to make sure that our security model is bound to the user and not just a single user. It also works in multi-party uh uh in multi-party experiences. Um
[15:57] For one of the things that Asana does is that an AI teammate's effective access never exceeds the person who triggered it. So you could have a project which has an AI teammate in it. Uh that project could be, you know,
[16:10] there could be multiple people interacting with that agent in that project. And we will make sure that the agent has the smallest scope, right? So it it is the the intersection of what
[16:22] was the agent given access to and what are the people in that project given access to and taking the minimal of that. And lastly, there there's attribution by construction, right? Every agent is named, every action's queried. We keep a log of this. So this allows you to have
[16:36] that audit trail in case you ever need it. I think what's clear for to us is this is an ecosystem problem, right? It is no there's no single player, no single vendor that is going to go solve this,
[16:49] right? We'll not go through all the lines, but you can see like there is, you know, who provides the credential? What is the orchestration plane? Where is the data or the resource that is going to be acted upon or being queried?
[17:01] And each of us have a part to play in this. And this isn't, as I've sort of referred to, this isn't just hypothetical. This is not just architecture of the future. This is the stack that we are running on, right? Asana is a One Password the
[17:15] So we may we use uh one password to storing our credentials and what you know, secrets. Asana brings the context. It brings the work graph. So, uh more than just being a layer where
[17:27] teammates can execute, we make sure that we provide the governance. We provide the checkpoints. We provide the controls. And of course, we're here at this conference, Databricks and Unity Catalog provides where the data sits and gets governed, right? So, it requires
[17:40] all three of us and all three types of vendors to make this happen. Um with that, I'll pass back to you. >> Yeah.
[17:54] So, now that we've heard um you know, about each of the the components, right? From the credentialing, the identity layer to, you know, the agent reasoning layer to now the data plane layer, of course, with a deep dive on identity from my very own, you know, Jeff Melnick here,
[18:06] right? Come definitely, you know, ask us questions as well about how we're thinking about scoped access, you know, various delegation flows. And of course, most importantly, especially for security folks in the room or CISOs, right? How you can do forensics after
[18:19] the fact or even better, how you can proactively prevent, you know, over permissiveness or breaches before they even happen. So, thanks for having us. >> Thanks, everyone. >> Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.