How 1Password is Building Agentic AI Security and GenAI Discovery

All right. Hey everyone. Uh, it's awesome to be back here this time with, uh, one password.

Uh, I recently joined as the VP of product and ai, and I'm here to talk about one password and ai, everyone's favorite subject. So, to start off, I want to talk about how we're approaching AI from a principles, uh, perspective. Uh, Leah talked a little bit about our secrets, um, you know, differentiation, sort of how we think about that, but actually there's like a 70 page white paper out there if you Google one password white paper that actually talks a lot about our principles and our, our methodologies and things like that.

Um, but for user credentials, right? And so we decided we'll give this a bit of an update for AI and sort of let me talk through that a little bit. So the first one is how we think about AI is from a secret standpoint is for raw credentials.

We wanna adhere to the exact same model security model that Leah mentioned, which is that we should not be able to decrypt your rock credentials, right? Um, so what that, you know, that ties back to the two key secret derivation as well as the zero knowledge architecture, but that's gonna remain. Um, the second principle is authorization must be deterministic and not probabilistic.

So recently, um, there's been a standard called the model context protocol, or MCP in the AI world, which allows LLMs to interact efficiently with tools and resources. Um, and there are some solutions out there that actually reduce or release raw credentials over this channel. Um, but the problem with that is that the even MCP actually has a prob like, um, an the authorization channel, which is deterministic.

It actually uses OAuth and a probabilistic channel, which the LLM drives. And so releasing credentials or authorization on the probabilistic channel doesn't seem like a very good, uh, practice, right? And something that the LLM can see.

And so our approach is, no, not for rock credentials, but we do support MCP for other use cases. Um, the third point actually ties back to the second point, which is that you shouldn't be putting rock credentials into the context window of an LLM, right? And, and for instance, using like, uh, releasing rock credentials over, um, uh, MCP as an example is the equivalent of typing in the prompt window.

Hey, here's my password for this service. You know, please use it on my behalf. Enter, or here's my API key.

It's not a great thing because obviously it increases the chance of leakage, right? Of, of those credentials. And so just from a principle and a best practice, um, that's, uh, we don't approve.

Um, the fourth is auditability. So, you know, obviously there's auditability even when users go and access different applications and tools. Um, but the bar is much, much higher for ent ai, right?

So we need to know, you know, where those credentials were used, why they were used by whom, and, and all of the, all of those things. Um, the fifth principle is be transparent, right? So in the product, you know, as we sort of incorporate ai, right, to sort of enhance the product and delight customers, um, we wanna be transparent on exactly how that's used, what data is getting sensed, right?

What this LLM is doing, right? We don't want sort of, um, kind of like opaque powered by AI where you don't actually know what's what's happening. So we wanna be transparent about how we use ai, uh, in the product.

The sixth is least privilege and minimum exposure by default. I think this one's pretty self-explanatory. Uh, and the last one, I think Leia talked about this really well, which is that security and usability are core requirements, right?

A solution that's not usable, but super, super secure. You know, nobody's gonna use it. People are gonna work around it.

And because we came up from consumer, you know, it's, it's a very natural thing for us. Alright, so then now how do we look at ai? Now that, that's, that's established, um, there are two main sides of it.

There's one which is, uh, incorporating AI into the products that we have as well. Um, and that includes all of our products, you know, enterprise password manager, trca device trust. And that's gonna be an ongoing thing as we sort of incorporate, um, like the value and the features that, that, um, these solutions bring.

The other side of it, which I'm gonna spend a little bit more time talking about today, is security for ai. So this is using one password products to ensure that ENT AI is securely deployed and managed, uh, in the enterprise. And this sort of ties to kind of two personas in the enterprise.

There is the IT and security folks who have to actually manage and have visibility around ent, AI as they access enterprise resources, for example. Um, and then there are the, um, a, like developers, right, that are using, or that are developing AI apps and using AI IDs and things like that, that, you know, we want to have a quick, like an easy way for them to incorporate one password in a similar way to how both Jason and Leia just talked about. For example, with SSH keys, we'll talk about it more.

So double clicking on the security for ai. So the mental model that we have, uh, is basically, there are two main types of ent, ai one, and, and they're differentiated by how they interact with applications. So one is, you know, you might call a browser use style ENT ai.

So this is an ENT AI that drives a headless browser in order to interact with the world, right? Um, and this browser could be on your laptop or it could be remote in the cloud. And it's an LLM that's sort of driving this.

Um, the other type of ag agentic AI is a programmatic agentic ai. So this is the kind of agentic AI that would use APIs or use MCP to talk to different applications and do so sort of programmatically in that way. And these two ais access applications that some of them are behind SSO and some of them are not right managed versus unmanaged.

Um, and the lines aren't like super thick between these, there's lots of overlap. Uh, in fact, uh, OpenAI released, uh, released a product called agent, I think like maybe a month ago. It has both of these capabilities, right?

It can do programmatic and it can do browser use. So there's lots of overlap. But for the purpose of solutions and how we address the problems and where the different problems are, this is a useful mental model that we find in terms of, uh, breaking this up.

So, I mean, one obvious question to this is, well, why can't we just apply the solutions that we have for traditional applications, right? Like, do we need anything new for agen AI is sort of a natural, natural question. And the answer is agen AI is actually fundamentally different from traditional applications.

Um, and here are a few few reasons why. So, traditional applications are deterministic, right? I think we, we wrote them, we know exactly how they're, they're gonna behave.

Um, agentic AI on the other hand is probabilistic, and you have this sort of misalignment problem over time, right? Where maybe for the first 10 minutes, the Agentic AI is doing exactly what you intended it to do. And then minute 11 comes along, it goes off the rails.

That can happen with, uh, agen ai. Um, with traditional applications, we typically refine granting an independent access. Um, so, you know, system-wide access to various, uh, tools and applications.

Um, with Agen ai, um, this isn't for all the cases, but hopefully it will be for most of the cases. Uh, it's typically human delegated. I authorize the Syngen AI to do something.

For example, in the MCP protocol, the OAuth, uh, side of the authorization is human delegated access, right? I approve this thing to use credentials on, on my behalf or have this, this access on my behalf. Um, the other side of this is, you know, if agent AI does something sketchy, you know, it's really hard to put one of those in jail, right?

So it's probably good for agent AI to be tied back to an actual person. Um, the third is that, uh, we're typically granted traditional apps, broad scoped access, um, even though we probably shouldn't have. Um, but with a agentic ai, um, you know, the analogy that that, uh, a colleague told me about was, you know, it's like a toddler with a hammer that's running around.

You really want to keep an eye on it limit. Its, you know, uh, what do you call it? Uh, access.

So fine grain time bound scoped access is really, really important with agentic ai. And then, this is probably the punchline here, right? Traditional applications behave like applications, but agent AI has kind of scrambled this a little bit.

They're actually kind of like users. And in fact, uh, in a lot of, you know, areas, you, you kind of hear about agen AI as becoming our future colleagues, right? Like, uh, there'll be a network operations, uh, agen ai, there'll be, uh, what do you call it, a sales agent, ai, a programmer ent ai.

And these things will have to use work workforce credentials to access things that, um, that, that, uh, we have access to as well. And so this really scrambles things, uh, in that sort of, there's this kind of u like hybrid user plus application behavior that agentic AI is. And so all of this is to say is that the traditional application method of alright, any kind of credential access or credential management or secret access or anything like that was, is typically siloed, right?

So you have your application team managing secrets for applications in say, like a secrets manager, like, or a Hashi Corp, AWS Secrets Manager, something like that, which is completely siloed from your work workforce secrets and credential management, which would say be in a one password, for example, uh, which is siloed from, um, identity access and management, which would be like an Okta or Microsoft Enterra. And Agen AI really scrambles these silos around because of this, these differences. And so authorizations need to be tightly managed and control and come from a single source of truth.

Is is part of the thesis about how this kind of changes changes things? I have a, I have a question. Sure, yeah, please.

Yeah. Because I agree with this is how I would like it to be. Okay.

But when I looked at that gentech, uh, ai, specifically with MCP, too often I'm seeing very coarse grained OAuth scopes. Yep. Um, I'm seeing it being very long live right?

Like I've said, the MCP can do it now you go forth and do it forever. Yes. Um, is that your experience too?

All right. Just wanna make sure, because I'm, I'm reading this, I'm like, I really wish it was fine grain time scope, but I don't see that in the field. Oh, This is pointing out the problems.

Okay. Yeah. Yeah.

Okay. Alright. Challenge.

Yes, exactly. Those are the desired Don't see that. I don't see that desire.

No, No, absolutely. You know, MCP is one of these things, the first iteration of it actually didn't even have security as part of it. Oh, yeah.

And sort of security's been coming into it. And so I think even, you know, the, the folks that are working on it and we're also involved in contributing to, to those standards as well is, um, you know, they, they understand that there's, there's more work to be done there for sure. Um, so yeah.

Alright, so double clicking one more time in terms of, okay, what is the state of the art in terms of these ais? What can we do today? Um, so for programmatic ai, right?

I think it's, it's, uh, like you said, right? I mean, you can use long-lived API tokens or you can use OAuth, right? Those are the sort of like two things that are available.

Um, and for browser use style agen ai, the state of the art is the browser use basically stops whenever a credential is needed, right? It pauses and waits for a person to actually hover around their laptop and actually input those credentials. So this is true if you go to like an open AI operator, for example, or a cloud computer use or these different solutions or a browser base, all of them, uh, have, have this kind of situation or you have to pre-pro provide your credentials into yet a third, another third party.

So obviously that's not great, neither of those, uh, scenarios. And in addition to some of those challenges, you know, we have the challenge mentioned before about no single source of truth for secrets management across, you know, agent AI and workforce. Um, we have the challenge that we really shouldn't be relying on these agent ais to manage their own credentials.

And actually, in an ideal world, we would fill credentials on behalf of the agent AI and never actually give the credential directly to the agent ai. Um, but even if you have that right, each time, you know, a credential is being used on behalf of an agent ai, even the risk of leakage goes up, right? The, the risk that one day you're gonna go to some, you know, chat bot and type, Hey, what is, you know, s password for this thing?

And all of a sudden it's gonna know, right? That that increases each time it happens. So rotating these credentials, revoking these credentials really important.

Um, and then the proliferation of out of date grants, right? This is, I mean, you know, I've connected my Slack app to like a lot of things and all, all that kind of stuff, and I don't think I've kept track of that, and I don't think there's a single place to keep track of that either. And so that's, that's obviously even more important with agent ai.

And then, you know, audit logging, obviously the, the bar is much, much higher as I mentioned before, and that has to be sort of, uh, improved for, for ai. So this would usually be the place where I talk about solutions, and this is where I'm gonna be kind of unpopular here. I think, uh, because we are gonna be announcing, we are working on solving this problem, and we are gonna, we have a lot of announcements, uh, in coming, uh, probably one in like literally a couple of weeks.

We have more announcements, uh, to follow that as well. Uh, but I, you know, my corporate marketing department is eyeing me closely, so I'm not allowed to talk about it. Um, but, you know, stay, stay tuned.

I, and I will say, yeah, from one point of view is that by outlining all the issues. Yeah, it's that's true. I mean, what Wolf is saying, like, I mean, you know, that is true.

And that first you identify the problem. Yeah. So you have identified the problem correctly.

There you go. Thank you. Exactly.

But I would also like to talk about solutions, but, but you know what, I can talk about our solutions that we've developed over time, um, that we have even available today, and they'll tie back, uh, to stuff that, uh, Jason and Leah have talked about as well, that, that sort of talk about sort of how we're thinking about this. Um, so the first one is actually, uh, we have a product called trca. Jason alluded to it.

Um, it does, uh, SaaS or app governance and SaaS management. Um, and so what we've actually built, um, so I, as I mentioned before, we don't support like releasing raw credentials on top of MCP because it's, it's just not the right design to do so, but we do support the protocol in general, uh, in terms of an LLM being able to efficiently utilize tools and resources and, and that, that kind of thing. So we actually built an MCP server on top of some of our trca APIs.

And I'll just show you guys a quick, um, you know, uh, demo of it, sort of like a guided, guided demo, but it's actually live, so you, you guys can do it, do it as well. Um, but basically what this is showing here, so this is Claude, right? So it's an agent ai, um, in, in the cloud.

And what you can do is you can connect it to our MCP server, right? So obviously by default, you're not gonna be able to ask it any questions about, uh, your enterprise data or anything like that. And so what you can do now is you can go over here and hit manage connectors, right?

And you'd be adding a custom connector. And so you add this custom connector and basically what you're seeing here is the remote MCP server that we have on top of the trca APIs. And so, you know, you sort of add this in, you say, okay, add, and now you've enabled Claude to be able to answer a question like, could you look through all the contracts and find the ones that are up for renewal?

Could you get the owner of the contract and draft an email and set up a meeting with them or something like that? Because now it has that capability that it learned through the MCP server that oh yeah, I have these new capabilities and uh, access to all these new tools and resources, uh, that you just connected it to. And then Sure, yeah.

What are we going from credential to AWA token, right? Because one password is not an A password wallet for MCP. Yeah.

So I think I just missed two steps in your demo. No. So this demo is more so us, you, this is the AI for security a little bit.

Okay? Right? All right.

In terms of, we have the trca software, basically you can access it via API today, right? But what we wanted to enable is an LLM to also be able to access that, that same data, that that's all already available. So in this case, we're just using vanilla MCP right?

To support this use case. But you'll notice that it's not the most sensitive of data, right? We're not like putting rock credentials or anything like that, right?

This is the ability to answer these kind of questions. And so that's what I'm demoing, right? Yeah.

And so you hit go and now it has the ability to sort of grab all this information and sort of, you know, uh, be able to do that and be able to draft an email and, and all the rest of it, right? So just an example of, I mean, I think this is all still in its infancy, right? I think probably most customers would be accessing our data by API, but we also want to be sort of supportive and forward minded on this and enable our customers to also access it via LLM or via Gen AI if they want to incorporate this kind of data, um, into their, um, into their processes.

So that's, This is Marian. Oh, please. I have a quick question.

Yeah. Uh, so using the connectors, are there any, uh, controls or safeguards in place for like overprivileged pulling data more than the user intended, like a privilege creep? Yeah, I mean, so basically, so what we've done today is limit the set of APIs that this thing can actually access, right?

It's read only, right? So we really kind of locked it down in that, in that regard. We do have guardrails around it as well.

And, you know, it's, it's on top of MCP, but I think there's probably a lot more to come in terms of as we expand the number of offerings that we offer through MCP and the number of APIs that we offer MCP going forward. And so that's, that's still to come, but yeah, this, this has that. Thank you.

Awesome. Alright, so the next thing, uh, I wanted to talk about, let's see why it's not full screen. Oh, there we go.

It goes back to full screen. All right, can we, so the next thing I wanted to talk, oh, can one second, I'm sorry. Just have a quick question.

Yeah, yeah. So I don't know T trca. Yeah.

So did Trca manage the authentication to whatever tool it saw on the backend? So, so Claude didn't need the credential because it worked through T trca tr Exactly, exactly, exactly. Trca gets that data through like a different means or whatever through the agent.

Actually Jason's gonna talk more about sort of the broader access trust gap and how T Trca fits in there as well. Um, so that's how it gets its data. And then basically the MCP connection is over the cloud, right?

Uh, to, to connect to the remote MCP server and MCP uses OAuth to basically grant access to, uh, the MCP client, right? And so that's, that's how that, that connection works. Alright?

So the next thing that I wanna talk about, uh, I don't know if you guys all know, but you're all vibe coders. We're all vibe coders now, right? That's, that's, that's how we write, write code.

And um, you know, in a lot of vibe coding, uh, what it tends to happen is we hard code a lot of secrets, right? So we just either, you know, put them in our code, uh, worse yet we put 'em in the chat bot and say, Hey, here's my credential. You know, like, just, just use it or whatever.

Um, you know, one level above that is maybe we make an environment file and put all our secrets in that, right? Which is better, at least it's in one place, but it's still sort of, uh, in plain text, right? But obviously there are better, better approaches to that.

And so what I'm gonna show you guys and sort of just voiceover is a demo actually that we showed how one password can make, um, these flows much more secure when you're using an, uh, integrated development environment like Cur Cursor or VS code or something like that, right? And so let me say that, oops. Uh, okay, so what are we looking at here?

Lemme minimize this thing. Okay. Sorry.

We're so, uh, a developer on the team basically built like a really simple app and cursor that what it's doing is it's connecting to a database. That's it. And there are a bunch of credentials here, like, uh, the host the port, right?

The username password to get into the database, just database credentials in general, right? Um, and so, you know, you sort of see it there, right? That's, that's kind of what's happening.

And what he's gonna do is he's gonna try. And so those are configured to go get those things from an environment file or an environment variable file. And so he tries running it, it's not, uh, it doesn't work because, uh, what do you call it?

There's no environment file yet. So what he does next is, you know, the first step of trying to make this a little bit more secure, rather than putting those, you know, credentials directly in the code, he creates an environment file and puts those, uh, what do you call it, credentials there. But obviously it is, this is a plain text file, right?

Um, and so, you know, uh, what do you call it? Obviously not, not, not the ideal solution. He runs it again, it works right this time because the environment file is, is now defined, right?

So the next step is, and this is uh, what do you call it? Um, this is something that you'll see I, I'll I'll be specific here. Um, we're releasing this notion of environment file mounting within one password.

There will be, we're releasing it as a public beta very, very shortly, right? And you'll be able to use it. This automation with Cursor is not available just yet, as in like you can do the environment stuff that will, you'll see in a sec.

But, uh, what do you call it? Having this button down here or being able to interact with the chat bot and just be like, Hey, can you secure all of my credentials? Or whatever it is using one password.

That's something that's, uh, TBDI mean, it's, it's something that's, some of our folks are sort of like at, at work on, but, you know, not, not not available yet. But in this demo, which you'll see is sort of a version of that like, of sort of like a aspirational thing of like, okay, you know, you have this environment file here and he scrolls over this and says, no one password environments were found for this workspace, click here to import. Right?

And, uh, you know, he sort of clicks it, it'll open up, uh, you know, like the actual environment file that is to be imported. And what's gonna happen is it's automatically gonna pull up one password and Sorry. Yeah.

And in one password there's a developer section that everybody has access to, right? Um, and basically it will ask, Hey, do you want to import this file? Right?

And so what it's gonna do is, you know, you're gonna sort of put in, you know, what, what you're gonna name it or create a new environment for this, right? Uh, or, and then just, I think he calls it something random here. My cursor demo, import the project, right?

And then, let's see, and then that's, that's the, the path that, that's gonna get imported. And he does the import, right? And so what happens here now is that environment file, which basically had a bunch of key value pairs, right?

Like the host, right? What's the value of that? The what's the username value, the DB username, the DB pass password, and so on and so on.

All that just gets automatically imported. You can actually edit and sort of like change values and stuff like that inside one password as in, you know, just in in the UI as well. Um, but basically what's happening here, um, so I think he's just gonna show that you can reveal the value and stuff like that, just like you can do in a, in a regular password, uh, password, uh, manager.

But what's happening is the destination is actually that directory which stored the environment file. And what happens here is that now that file that's actually sitting on the local directory is just A-F-I-F-O file. So it's actually just connected back to the file that's mounted in one password.

So you can't actually, like that file on disk or whatever it is, is actually linked now to the, to the one password file. And so in that way, you're not gonna like accidentally check it in to get right and it's also now secure. Right?

And so you'll see sort of how, how you see it as, as, or how it sort of manifests, um, in that. Okay? So what he's gonna do now is basically go back to the IDE and just run that script again.

So over here he's gonna run this thing, oops, make sure it's playing. And then basically when he runs that script, now it's gonna pop up a auth prompt for him. 'cause that file is now secure, right?

As in it's, it's inside the one password vault. So to be able to access it, you have to actually give it OAuth authorization and you'll be able to control, okay, do I wanna authorize this, you know, for some time? Or, you know, do I want the auth prompt every single time?

Like, and, and things like that. But now you've gone from a case where you had a plain text file on, you know, on, on your laptop or in your development environment to having it automatically in, in one password. So another example, I think very similar to the SSH key example of a very common use case for a developer that can easily sort of be able to make that far more secure in, uh, in one password.

So I love that. I think that's an absolutely brilliant feature. I'm curious as to how that works for a developer that doesn't have one password or when you move it into more of a production or test envi an online environment rather than local in your laptop, Right?

Right, right. So, so today this does only work for one password customers. Okay.

So the answer would be you should get one password and then, and then you can, you can have that feature. Uh, we are, No, I mean more specifically. So if you have a developer that, like you have a new developer, he's not set up or whatever, and he goes and tries to, does a checkout, he's got this NV file that Yeah, yeah, yeah.

Linked to a one password database, but he, he doesn't have that yet installed. So what's sort of that experience then? Ah, okay.

Okay. So, so this presupposes that you do have one password on the laptop for it to like detect that, right? You have one password and you're able to link it.

Um, for the production thing though, that you were saying, we are sort of working on that as well. So we have two thing, two, uh, features today that can actually handle it. One is something called secret syncing.

Mm-hmm. Where one password is the, the source of truth. But let's say you're managing that secret in AWS Secrets managers, right?

Something like that, right? Oh, so we can actually sync it Okay. To AWS Secrets manager.

And that's something that, you know, we'll, we'll be sort of adding more to that. And, and that's, that's one way, but we're actually looking into other ways where you can directly support one password on the other side. Mm-hmm.

And, uh, you know, use, use like a similar, similar feature. Oh, Sorry, go ahead. We'll back up with that though.

Like, that's interesting, right? Because from a security perspective, we want to have centralized governance of our secrets and be able to run reports and everything else. Developer side, they don't wanna change a thing.

They're using AWS or they're using Azure. Yep. So is what you're saying is I could control the governance in one password and control the last mile in AWS or Azure and the vaults.

Exactly. You can do that. Exactly.

Exactly. And, and that's still sort of like the exact flow, the exact type of audit logging and stuff like that is still sort of an ongoing Yeah. Kind of, uh, conversation.

But that's the idea that we wanna make sure that centralize the single source of truth, right? But then, okay, the last mile, as you said, right. People may want like a different vault or something like that, right?

I mean, but for us it's also, is that a trusted vault as well? Yeah, yeah, right. That we're sinking to, you know?

Right. That's clever. Is it just AWS or is it Azure?

So today we support AWS Okay. That's, that's the first one we, uh, I Snuck in, I snuck in Azure, and I want to double check that exactly. Is that, is that a feature request?

Wolfgang? Awesome. So, so that's, that's, uh, one of the other things that I wanted to show you guys.

And then one last thing, and then I'll hand hand back to Jason, um, is we recently announced a partnership with Perplexity, um, to be a launch partner with, with their, uh, browser. So they have an AI browser that they have. Um, the, the scope of the partnership really is that we're the only password manager or browser extension that does password management that is launched with them.

And the goal for us is for people that choose to use perplexity, we want them to use it securely. We don't want them to memorize passwords or use post-it notes as Leah said, or anything like that. So our browser extension works, but there are a lot more announcements coming in terms of, okay, well that's the vanilla browser extension that you can use when you're using perplexity locally.

But what does this look like for like a remote browser in the cloud that's driven by an AI or you know, an automated thing that you want running on your laptop. And there's more announcements to come, but course they can.