Getting Visibility and Control over SaaS Sprawl with 1Password Extended Access Management

I wanted to, um, come back up and talk a little bit more about this visibility and, uh, control problem that we have, thanks to the access trust gap, sort of created by the SAS sprawl that we have. So it's important to understand that we're sort of in the middle of two major shifts that have significantly changed the way that we have worked, right? I mean, I remember when I started my career, I'm 40, so this was in oh seven.

And back then, every aspect of my experience from an IT perspective was fully controlled. I would go to an office, do an assigned cubicle with the device that was physically given to me and I was given, um, A-V-P-N-R-S-A thing and I couldn't do anything that wasn't fully sanctioned by the IT and security team. And we were able to, as a collective community, like security and IT protect practitioners are able to achieve their objectives.

'cause users, they didn't have free will, right? So the world that we're in now, we have to deal with the fact that users have a degree of free will. They have the opportunity to choose the apps that they want to install.

They have an opportunity to work primarily from wherever they want. They don't have to use the VPN every time to be able to do their work. And a lot of the, as an entrepreneur, one of the things that I was taught was, oh, get users and bring up new enterprise apps via grassroots.

Like this is a known way to get applications installed throughout an enterprise is start from the bottom up. That would've never been possible in the nineties, in the early two thousands. And so we need to change the way that we think about solving these compliance problems in the access trust gap by taking a page out of how every other industry does it, by bringing this problem to the end users, educating them, giving them information, and more importantly, giving it security, the visibility they need to enumerate this problem.

So the truth is, is that this problem has gotten really, really bad. I think we've sort of fooled ourselves that maybe we're getting this a little bit more under control lately with the, uh, introduction of tools like Okta and other SSO providers. But we've just sort of created this bubble that we live in and we've sort of decided, yeah, we know there's a little bit of that nonsense out there, but it can't be that much, right?

Well, the truth is, is that this is exploding and if you look all the way on the right, this sort of unmanaged piece of it, there's a lot of AI tools in there. 'cause these things are popping up every day. And not only are they apps that we don't really have visibility and that they're being used, but they are often encountering and intersecting with some of the most important and secret information in our companies.

It's like a nightmare. So this is a slide that's familiar, but we're gonna talk a little bit about how all these things come together, sort of help again, uh, enumerate this gap. I'm gonna talk about the AI problem, which is actually really unique.

The thing that's really tricky about AI is that it's more than just web apps. They're really SaaS services that have a physical or local app component to them, which makes them especially hard to find, especially if the way that you're typically relying on finding these things is sort of like, sort of centrally like scanning emails and OAuth tokens. If you don't have more visibility than that, you're gonna miss this stuff.

And then we're gonna bring Ethan up here to talk about trca, which is this incredible tool that allows us to enumerate all the shadow IT that's out there, get it under management, and then gives us some really cool superpowers so that not only can we learn that it exists, bless it as an an, an official app in the company, but we can start doing some really exciting things about managing access to that app based on the properties and the lifecycle events associated with those users. And we will show how we bring that all together in what we call the One Password app launcher. This one unified place where you just click on an app and regardless of the implementation detail of how you sign in, we get you in safely and securely every time.

So with that, I'm gonna do a quick demonstration of the, um, AI discovery capabilities of device trust. And then we're gonna swing over and we're gonna show you a little bit of one password access governance previously known as Trica by one Password. So right now I am in Device trust again, and I'm looking at, um, a series of apps that we've discovered utilizing the one password device trust agent.

I've already pre-filtered this list by AI and machine learning applications that you give a sense of all the goodies that I found here. And we could see the number of people in this, uh, smaller organization who are using these tools and we could decide whether to accept or deny these tools and learn a little bit more about them. So if I click into one, let's click into chat GBT for instance.

I get a nice summarization of what this program is. We all kind of know what chat GBT is and then give us all the information we need to do to understand why do we think that people are using this. So there's two mechanisms that we have today through the agent that we can use to identify usage of these applications.

The first is browser visits. So the agent is actually capable of looking at Firefox, safari, all the variants of Chrome and using a really privacy forward way scanning the, um, the history file to know whether or not specific patterned URLs are being used. This is all done locally, so we never actually see an end user's full browser history.

We only see the specific and curated URLs we're looking for that are directly associated with these services. And if you're an end user and you're maybe worried about this, we have a whole privacy center for you to look at. It tells you who can access the data, what checks do we have enabled.

That's what I showed you earlier. And more importantly, what types of apps are we looking for in terms of looking at usage both on the browser and then locally native. This is available to every single employee that uses one password device trust and they can get a good understanding of what their administrator can see.

We do this not because this is something that we expect companies to use when they have it rolled out via company owned devices, but we also wanna make this a plausible, uh, agent that people can install on BYOD, particularly laptops. Is this is your discovery only browser history or do you also have like email integrations and those sort of discovery methods? So We'll show you a little bit more.

We actually have some exciting stuff on the trca side, uh, that kind of marries all this data together that shows it on both OAuth secrets and grants and also some of the capabilities we can get through an extension in terms of understanding usage there. Now, what's valuable about that is that we can also get usernames in that case. So for actually looking at authentications, we can know what a user is.

If we're looking at browser history, we sort of have to take that leap of faith that if they're using that particular service, they're using it for a work purpose. But no email. We do not do email scanning as of this time.

Alright? Yeah. Alright, so I talked about browser really quickly.

Let's look at desktop apps. So one of the things that's really tricky about these AI tools is that they kind of get their feelers into everything, right? app.

How many people here knew that chat GBT had a Chrome extension just for search? I didn't know that existed. How many folks did that?

They had a direct vs code extension. I didn't know that that was a thing. And so we are able to crawl all of these different areas.

So every type of browser extension, um, IDE plugins, um, native apps, and we're not just talking about Mac Os, we're talking about Windows, we're talking about Linux, and we're talking about, um, all the different plugin systems that appear in those, in those things. So if you're looking at Debian packages, RPM packages, these are all things that we can bring to bear in one unified view that's associated with this, this SaaS application chat GBT. And this gives us great visibility into, um, into that issue.

But what if I wanna do something about this, right? Okay, now I know that this is being used. I can either accept it or I can deny it.

Well, this is where checks become super, super powerful. So if I go to checks really quickly, I'll just search really fast for that GPT, oops, I spelled it correctly. And you could see that we're offering all these different flavors of checks that are associated with the service.

And the key to this is that it's meant to be nuanced. There are gonna be some people out there that simply do not want people to use chat GPT at all. We just don't want you to use it.

This isn't a sanctioned application, it's vebo. But what about the nuance? And this is where we think this sort of middle ground is really important.

If you sign up for chat GBT as your company and you get an organizational account, you now have the ability to get a little bit of governance of what people are actually using that service for. You get some audit log history, you could kind of set some rules of the road, you can limit some of the functionality, but what good is that if your users aren't even using that org? So we have a specific check here that ensures that when people are linking chat GBT to their native web app or to the Mac app, they're using the correct workspace that you said is the one that they should use for work.

And if they don't, we won't let them use chat GBT at all. We'll block them on the website and we won't let them sign in to your most sensitive and secure applications. We'll use that stick to prevent them from doing this until they understand this policy, fix the issue, and then they form in compliance.

So this is the power of device trust. It not only allows us to make sure devices are secure and compliant, but as I had mentioned earlier, you're allowed to use this to convey very nuanced policy and go as deep as sure chat, chat GBT is fine, but we really need you to use the corporate sanctioned account. And if you're not doing that, we're not gonna let you use it.

And you have 3, 4, 5 days to comply before you do. So this invites a back and forth conversation and people feel a little bit more comfortable using these things and you end up being in a place where, um, you effectively have a little bit more control over this story. And on the other side, you can ban all the ones that you really don't want them to use.

So if you don't want 'em using deep seek lock, deep seek, um, and start to direct them towards the approved and, uh, thought through tools that you want. Yeah, go ahead. How, how are you seeing what workspace they're in?

Is it I sigh because the amount of labor it took to do this. So, um, we have a, we have a crack checks team at, uh, at one password. Their entire job is to look at some of the most popular applications and we reverse engineer how they function.

So for chat GT app for example, which is a Mac OS app chat, GT stores, the logged in accounts in a file called the P list. Mm-hmm. That p list is in a known location.

Our agent has raw capability to read that P list and then we can basically build an interface where we just ask you for your account ID and then we can make that happen. So this, for every, uh, AI capability we wanna support with that nuance. We have to extend the agent's capabilities or build our own check to be able to make that happen.

You of course can also do this, but it's really hard and it's, it's often better if we collaborate and that's part of your service when you sign up. We'll, if there's things that we don't have in there for you, part of what we do is we work with you to make sure there's check coverage where you need it. So, uh, yes, it's in the P list, but how do you, 'cause I, I could log into my personal or my, so both of mine are in my p list file I assume.

Mm-hmm. I actually never looked. How do you know if I switched to my personal?

Oh, great question. Great question. So we do know that and um, the way that we do that is in that p that same p list, there's a special indicator to show which, uh, organization is actually physically selected.

And so we read that P list and we monitor it for changes. Every time it makes a change, we're able to detect that, oh, this is no longer set as the primary one. What's nice is, um, so you can do it both ways.

You could say, you know what, I don't even want them to have the personal one on their period. Or you could be like, no, it's okay if they have it. But during, when they're accessing, you know, when, when it's, when it's for work purposes, it really should have that one more the be the active one that's selected.

So we go to that depth and it's not easy, but it's something that we think is important because if you take a blunt instrument to this problem, all you end up doing is blocking and banning everything. And as a security practitioner myself, um, the one thing that I hate is this idea that security people are the people of, no, we're not, you know, we want to be enablers and the tools that we inherit often make us feel like we're the people of no. But if we build more nuanced tools that get that balance right, we can be the people of yes.

And, and then kind of inject a little bit of that nuance and get visibility into how well it's that adherence is and then convey that instead of one long document conveyed in real time to people who are actively messing it up. And that means if I don't have chat GBT on my computer at all as a user, I don't see a thing the second I get it on there and I only have a personal account. We're gonna be knocking on the door and we're gonna be asking you to fix up some things for us and we're gonna tell you why.

So that's our perspective of how to use Device trust to get good AI discovery and to bring the policy to the end user to make them feel like they understand what's going on and direct them to the past that we want them to take so that they can use AI safely and efficiently within their organization. Alright, I am gonna stop there 'cause I could keep talking about this for hours, but you guys haven't seen T TrkA yet. And TrkA is probably one of my favorite parts of one password.

It is everything that we are talking about when it comes to us taking apps that can't traditionally be fully managed by a traditional IEP and getting management around them and discovery and then plugging that in to the one password authentication experience. Uh, so that we're gonna bring Ethan up and he's going to go through it. Sweet.

All right. Hi all. Uh, my name is Ethan Stoller.

I am one of our senior demo engineers at One Password. And I'll also be taking you through a live demo here. Um, like Jason was saying, I've been using one password for 12 years.

I got very excited by, uh, T Trca and actually starting to get into use it. So very excited to show y'all what we've got today. Um, so logging in here, uh, again, T Trca is gonna be our newest addition to the extended access management suite of products.

So this is gonna help you control and manage any app governance and all of your SaaS management. So, uh, really bringing everything into one single pane of glass for you to be able to see how people are interacting, uh, as well as working with what we discover in the Access trust ga for any unmanaged applications as well. So really Trico works with three key pieces here.

Uh, first we are integral with connecting to your identity provider to pull in that initial source of truth for, uh, people and applications that you're already aware of and managing. Um, we also integrate with different spend data, so pulling in from financial systems, cross-referencing that for any, um, individual expenses for applications that you might not be aware of or, uh, procured outside of a formal process. And then finally, we do have the trca browser extension as well to cover any of the remaining gaps for what people are actually using in their day-to-day, uh, signing in using a business email address.

So here in the dashboard, um, as an admin, uh, we're gonna see everything that we're aware of. So those managed applications, all the people we know about approximately how much we're spending and other things like upcoming contract renewals or, uh, workflow runs. But here we can also see any newly discovered applications.

So again, this is pulling in through the browser extension of someone signs in with that business email. This is also pulling in and identifying any sign-ins using OAuth. So when you connect to Google or Microsoft, they're using that sign-in with Google Microsoft button, again, using a business email address.

We will, uh, collect that in here and surface that for you. Um, but we can automate all this as well. So having those integrations, excuse Me, sorry.

Um, So you're detecting this based on what you consider a business email address or like the registered domain of the company? Correct. So either the business email address using the browser extension, or of course if you've connected your, uh, organizations, Google Andra accounts will pull directly in from there.

Okay. Yep. Another question earlier, this was tied to an IGA process.

Uh, I know there's versions of this type of approach that use like RP or something to provision or deprovision or put people in specific app roles. Is that a part of this? I see workflows, Yeah.

We'll get into workflows in just a second, but that actually leads me into applications. So again, starting out with our managed applications, at least these are the things that we know about that we do wanna provision folks into. Yep.

And control those permissions. If we go into Postman here as an example, this is where we can start setting up the baseline for those workflows. So in here, uh, postman is an application that I want everyone to be able to have access to.

So I'm gonna set up an access level that gives everyone that immediate birthright access as soon as they join the company, um, they don't need any type of approval, we could apply an approval, but since we know we want to give this to everyone, we're just gonna leave that as is again, with, uh, over 350 plus integrations that we have. Depends on the application itself. If they have API endpoints that support, that provisioning aspect, tr click can handle that as well.

So in this case here, we are gonna provision directly to Postman for any new users that get invited or get added to the org. You said three 50 integrations. Is there like a universal integration or something that can be done if we have a one-off or customize if we have a one-off?

Or are we limited to the integrations outta the box? Yeah, so really the end application, the Target application depends if we have an API that we can utilize for those that we don't. Uh, you can configure manual tasks as well.

So, uh, this would come in, again, we didn't have an API any type of integration. It wasn't hooked up to the identity provider. We could just create a manual task and say to the it admin, the app owner that's assigned to this app, Hey, this new user signed up, here's a task.

Go provision them with this set of access that we're defining in here. Nice. Got it.

Yep. Thank you. And again, with integrations too, if you have something like Fresh Service, Zendesk, Asana, uh, we can sync all of these tasks over to those systems as well.

They're marked completed over there. They get marked completed int Trca. So going into those workflows, um, and specifically talking about app governance, this is where we start looking into centralizing onboarding and offboarding workflows as well.

So taking a look at our onboarding workflow, it's gonna do a couple simple tasks here. Just getting a user set up. Um, so we're gonna create a manual task to actually, uh, create an email for them.

Uh, this is just in our demo account. We're gonna create an Okta user, Google Workspace user, and then we're gonna send that new person all the information that they need to be able to sign into those accounts and get started. We're also gonna go through and generate an access plan.

So those access levels that I set up for Postman saying everyone gets this for Birthright, maybe also have Workday. If you're assigned to the HR department, you get birthright access for like an admin level permission. Uh, this is gonna collect all of those settings that you've applied for that specific user and the team they're joining and start to generate those requests in the background.

We also have interactivity built in. So between Slack and Teams, we could send their line manager a message and say, Hey, we have determined that this new hire needs, uh, access to these 10 applications. Does this all look right?

Once they approve that, we'll run the access plan, send another email saying they've been set up and they've been onboarded. Same thing for Offboarding here too, just as another example. Uh, this is a little bit more complex because they've actively been working in our systems.

Um, they've been making changes, they've been working in Asana, different applications. Uh, we actually want to go through automatic automatically to clear and revoke all sessions. Maybe we wanna lock devices that have been integrated with our MDM.

Um, maybe we also need to go through and reassign their Asana task to the line manager. Again, this can all be clearly defined in a workflow that's easy to manage by anyone who comes in here with us handling the API requests in the background. So no need to go to multiple Google Workspace, uh, pages to do all these actions.

No need to go into Asana. Everything can be clearly defined and outlined here in our workflows. So putting on more of my end user hat on here, uh, this is where we start looking at App Launcher as well.

So, uh, let's say I'm starting my day out here and again, I need to get into Postman to start doing my work. Uh, now I could come in here and just search for Postman. Uh, this is gonna bring up any applications that t Trca knows that I have access to.

Uh, again, either via the integration or just manually setting those up. Uh, in Tica, it'll also pull in any items that we have saved in one password directly. So this is where we have everything living within this search bar for these top applications, these most recent applications.

You can also see we have Device Trust here in the top right, but I'm actually gonna run into that when I go to sign in here with one click into Postman. So go through, verify my device real quick, I'm good to go. I do have an unencrypted SSH key, I'm a guilty one here, but I'm actually not gonna fix that right now.

And we'll just go to finish signing in and now I'm into Postman and can start my day out here. So that's pretty much everything that I wanted to walk through, kind of how we bring all three products together into that one central space and how we can bring all of the SaaS applications and governance for each of those into one single pane of glass here in reca. Making that easy to manage and report on get access to.

Um, Oh, one additional question. If I've got, um, an SSO portal, right? My apps dashboard mm-hmm.

Off my IDP for everything that's federated. Mm-hmm. Then I've got a second one for trca or is there any, do you have any like combined This is that combined?

So, uh, again, the IDP is gonna be for things that are just federated. Yep. But maybe you have applications that aren't federated with SSO, this is where, again, you can mark those as managed.

You can define, uh, sign in URL and then it's added into that same app launcher as well. So maybe it is something that's stored as a username and password in people's one password accounts. Um, maybe it is an OAuth application that you are aware of in managing.

Again, t trca is aware of all that. You can update the status here and it would be available in Your customers would take like their intra app launcher and just move those apps into this for one combined use. Yep.

Correct. Okay. All Right.

And does it, so if I have something on here box, for example, that we log in through Okta, through saml mm-hmm. Does it send them through Okta? Mm-hmm.

I click it here. So just like we saw here signing into Postman, this is an application managed through Okta. So I am going through Okta signing it.

Okay. Yep. This is Mion, uh, doing that onboarding.

Is there any safeguards in there to check for like, uh, stale entitlements, uh, suspect SA apps? Uh, you can go through and build in any type of, um, check in here if you need to wait for a different action. Um, so we could go through and just do specific, we need to wait a certain amount of time.

Maybe we also add in a task for specific IT admin to go through and, uh, complete something before the workflow continues. So, uh, you are able to build in pauses and breaks in here for what needs to be extra controlled. Thank mm-hmm.

Can you then go ahead and do you have a workflow or build something, or how would you think about on the opposite side of the employees leaving or changing roles and needing to, to terminate all access to apps? Yeah, so again, since Trca is aware of everything that they have access to, uh, this is one step that we have at the end of our offboarding workflow is to offboard the person from all apps. So again, that's gonna follow the policies that we had set for each specific app, whether that is deprovisioning them from Okta, removing them from a group, creating a manual task to take them out, doing the exact opposite of that since it's all noted with those access levels.

And you can see over here too, maybe we do wanna change the offboarding policy to specifically do a task instead of automatic deprovisioning. So this is fully customizable for anyone's workflow needs. Gotcha.

I guess lastly to point out here too, so we've been talking about access levels, things just appearing. Uh, we do also have, uh, the end user's view of T trca. This is the app catalog.

Uh, so they can come in here as again, that single source of truth for them to see all the approved company applications. Um, and again, seeing specific information about each of those trca will pull in a pre-populated profile, giving them a quick description type of category for the application specific product information as well. Um, and who they can go to within their own organization for more support on this, of course, in addition to actually requesting access, so this is what they would see if they were to sign into T Trca, uh, something like Slack too.

We can also bring up the app catalog directly in, uh, the trca application as well. So if people are already working in something like Slack, uh, they don't necessarily have to leave. We can still kick off the onboarding and provisioning workflows all within Slack.

Let's go over everything that we saw today. As you can see with one password, we're trying to go far beyond our original remit of just simply securing credentials. We're trying to enumerate what we call the access trust gap.

We're trying to give you common sense solutions to bring those unmanaged apps, devices, and identities into the light, and then give you an opportunity to get them under management and then eventually get them under governance. Everything that we're going to be that we have announced this year, and we will be announcing the end of this year and an early 2026, is all going to be in service of this mission. Secure every sign into every app from every device.

And we really wanna do this as holistically as possible. So we're gonna be be chipping away at the problem little by little with every announcement that we make. So you may even looked at App Launcher that we just showed you and thought, man, is that something I wanna replace with my, I already have a thing like that.

Well, the truth is, is the thing that you have already is likely just a limited slice of the total view of everything that that user can do. And our vision is for that screen to represent what your end user wants to do that day, and to take all the implementation details of how they get access and make 'em completely invisible to that end user. So if I click on one of those boxes, and it's not behind Okta, it doesn't matter, the one password autofill will automatically put in their username, their password, their TOTP, and then boom, they're in.

And if they need to fix something in Device Trust, they'll be prompted. And if it is Okta, you'll go through the exact same experience. This is incredibly valuable because it allows us to create what I call experiential uniformity.

Once you have that, we can go collectively the, we can go behind the curtain and start taking some of the most sensitive and unprotected credentials and start upgrading them. We can turn a username and password to a pass key. We can go from that pass key to some fully a fully federated SAML based app, and the end user doesn't even have to think about it.

They'll just click on the app the same way. And throughout that entire journey, security and IT team will know that they'll get all the guarantees that they want around that device being secure, that identity is known, and that they're accessing an app that's known and sanctioned within the, within the organization. So that's our vision when it comes to one password extended access management, it's gonna take us a while to fix, fix the whole thing, but as you can see, we're well on our way to doing so and appreciate your time today.

With that, I will leave the floor open for any questions at all about things that we talked about or things that we didn't cover that you'd like to ask that are related to one password. Happy to talk about anything. So with the ci cd pipeline, you know how we have the shift left type of idea or shift everywhere.

Um, is there anything as far as expanding deeper into that with a developer deeper into that password? So it's more to the left? Yeah, so there's some trends that we're starting to notice that we're actually very encouraged by.

Um, so one of the trends that you're gonna start to hear about, I think next year, but it's, I go to a lot of developer conference and there's like a little bit of a drumbeat about this, is that there's starting to reject the concept of centralized CI CD. The reason for that is this idea that we wanna take all of our most sensitive secrets and just throw 'em into the cloud because it's too hard for us to run. CI locally is starting to be rejected.

The reason for this is computers that we use development are starting to get really great. Like they can actually run the test suites often faster than the ci cd service that we're paying thousands of dollars a month for. So for those folks, we want to empower them to be able to source those secrets that they need to power that pipeline directly from one password locally.

Uh, you'll see this with our integration. Uh, we just had an integration with the Ruby on Rails framework on their deployment thing called Kamal, where you can actually do a local CD run and actually deploy it to production using the SSH key capability within one password and then sign an attest station that you did all these things and then upload that to like a GitHub source control to say that you did it. So that's one area where we're trying to help.

Um, the second area that we're trying to help is encouraging the rotation of all these secrets, making those easier by directly embedding ourselves into the development workflow. I can't tell you the amount of folks that if they get those nvs compromised, they're sort of flatfooted in their ability to actually go and rotate all those things. So we're gonna be working on a number of ways to make that process easier, to create the connections necessary to understand all the secrets that are associated with different production pipelines and things like that to help get that scope around that problem and get accountability and auditability how frequently those, those credentials have been reset.

So those are some, some of the things that we're working on and or have already done in that, in that vein Or that, sorry, or that on the rotation of the credentials. Is that something that you guys can automate so that the developer doesn't even know what they are? They just, they have access to that credential through their account, but they don't actually know what it is when they just execute their code?

It pulls in whatever the credential is at that time? Yeah. This is like the holy grail of password managers, right?

Like how do we inform someone that they have a compromise, which is what we have today with Watchtower, and then make it as easy as possible for them to do that reset, whether it's a password or an API key or whatever. Um, so the short answer is we have tools that help, but they're not the full holy grail. Like I just click a button and it's rotated and I can just trust that that work.

This is something that we firmly believe AI can help us solve, uh, with a, obviously a lot of human in the loop as well. It's something that we're working on. We have nothing to announce at this time related to that, but I want you to know that we're very passionate inside the company of solving this problem.

It's probably one of the hardest problems to solve in the password management industry. And, uh, when we solve it, which we will, we are going to solve it in a way that continues to preserve our privacy model and does it with a reliability that people can actually use it. There are folks out there that say that they saw this Well today, when you actually try to use it, you find that, well, it doesn't always work.

You kind of have to do it manually yourself anyway. We're not gonna be doing it that way. We're, we're gonna be doing it right with Open.

Oh, sorry. Um, so will you be doing anything to, for as so just sticking with developers, um, and the development community, developer community, uh, with open standards, be anything along those lines? Absolutely.

So one thing that many people don't know about One password is we are on the Fido board for pass keys, and we've actually authored a few standards recently. Uh, one the most recent is called the credential exchange format for passkey. So this is the format that allows two password managers or two credential managers to talk to each other to be able to transfer securely credentials between them prior to this format existing.

What most people would do is they would actually export all their passwords in a plain text CSV file. Yeah. Horrifying as that is.

They'd be all over the computer. That's true. And they would send it over to their friend, they would import it, and then they'd never delete the CSV file.

Like what a nightmare. Some of the password managers did come together and create like proprietary ways of going, but we're like, this needs to be a standard, especially needs to be a standard because of PAs keys. 'cause those don't really go into a CSV very well.

They're, they're clearly not suited for that. So, um, not only did we, we, we authored that standard and we were able to rally all the pasky authenticators to adopt that standard. And everybody's, and the precipice already has started to release their implementations of it.

So we're on the Fido board. Um, and we're continue, we have a lot of folks that hang out with the W three C folks that consortium and, uh, we're trying to expand our, our reach. And we we're definitely, we definitely think standards are the way of getting this done with, particularly when it comes to web standards around how these authentication flows work.

A couple of things that mc mm-hmm. Involved There as well. And OIDF, that's another standards body that's looking at these things.

Great. Lots to Jason's point. Very cool.

Yeah, we learned a lot. You know, we're new to it. Mm-hmm.

We've been doing it only for a handful of years and to have an opportunity to influence these, these sports. 'cause famously when passkey were first created, they were kind of like a little bit stringent on the rules of the road of what they could and could undo. And one of the rules was they have to be device bound, but we didn't like that because we want people to be able to have a p**i and then when they use their phone that those p**i are there, they can log in.

So, you know, kind of moving the Overton window toward a world where we could accept syn syncing these pass keys across devices is one that we help champion. And also differences of how user verification happens as well as a result has keys are a lot easier to use, not just in one password, but also using Apple and other types of operating system because of some of those things that we're able to kind of help move the needle on. I like that you use Overton window in that, because I was pretty outraged when I moved off device bound, so that's Appropriate use There.

Uh, question for you that I have is, as we look into the DevSecOps world, and you know, the, the injection credentials, those are some well funded, well entrenched competitors, right? Oh yeah. People are doing vaults nor injecting secrets.

How would you explain how far you want to get into that market? Right? Where does one password belong and where do you think you're gonna be like, ah, I'll leave that to the enterprise vaults?

So our perspective on this is we started where we always start with every problem is how do we make this easier for the end user, in this case the developer itself. And so all of our efforts on the developer side have been around how do, like our S-S-H-K-S-S-H-H agent, for example, that was built from the perspective of it's really hard locally to manage an SSH agent if you're not used to it. And, and then importing those keys and taking care of 'em in the right way.

This is just a really hard problem to solve. Well, that sounds so much like the password problem that we solved all the way back in the early two thousands. So let's do that.

Another good example that we will be announcing in the future is related to sourcing environment variables, right? Like it is such a pain, like you have these environment variables. How do we source them in without just creating, do NV files all over our local code base and they're just sort of sitting there waiting to be compromised?

Well, the answer is put them in one password and we will build the connective tissue to make it simple that when you open your terminal and you're in the right folder, they're just sourced immediately. Um, in addition to that, we have done a ton of work adding CLI tools to the password manage. So if you have the password management installed, we have something called the op command, which is I think an amazing two letter, uh, two letter binary to have on any computer op.

But you have, you have op and then what you're able to do is you can actually script your ability to actually reach out to one password programmatically to grab credentials. And not only can you do that, reach out programmatically, but every time it does it, you have to prove user verification. So if I wanna build like a deployment script that needs secrets that are sourced from one password, every time I deploy, I have to authenticate to unlock the vault and all of that gets audited and rolled up to a central authority.

So these are the ways that we really see, uh, us stepping into the space versus trying to make this big effort in going straight for the buyers who are trying to buy these full-fledged solution. We wanna start grassroots, we wanna solve the problem for the single developer that's just starting their company and then have it be brought in and then be proliferated throughout the org until finally somebody says, you know, this is working very well. How do we get an enterprise license?

It's how we built our B2B business, and we're gonna take that exact same approach as we approach developers. And we also think helping the folks that are experimenting with AI do it safely will also be our entree into that space as well. Yeah.

I just to quickly add to what, what Jason said, um, I, that slide that talked about sort of how agentic AI is kind of like a user as well as an application sort of also provides that entry point in the sense that, you know, all these secret management that was sort of like siloed in application teams before in enterprise vaults and things like that. Well, agent AI has needs access to those secrets as well, right? But also needs access to workforce secrets.

And so how does that situation, or how does that kind of a system work? That's, that's something that we're, we're looking to solve, uh, as well. So, yep.

I hope I answered your question well. Oh, sorry. Oh, sorry.

Go ahead. Um, what happens if any issues with losing a master key and retrieval of that and Yeah. So we've Yeah.

Can, can your information be forever encrypted and you can't actually get it? So we've thought very carefully about recovery, particularly for the enterprise use case. Um, yes, there, there's still possible paths for you to be locked out, but on the consumer side, we're there right away to give you that one pass of recovery kit, give you options to so that you can't lose it.

And then this is where my knowledge is, I'm still kind of getting used to it, so maybe if Leia knows a little bit more, but we have a really, really cool way of using sort of this consensus model to get you back your access if you lose it for an enterprise account as well. So I'm gonna do a terrible job of enumerating the specifics of that recovery process because I've never actually had to go through it, but I know that we had a big team think about it for years. And what we have today is, I think, pretty state of the art.

We never want people to obviously lose access to their stuff, but at the same time, we don't wanna compromise our zero knowledge architecture either, right? So we're very careful about we have to spend three years to solve that problem. We're gonna spend three years to solve that problem, not compromise on the values that made one password what it is today, which is that double encryption standard.

Yeah. So just Le why don't you, uh, I'll elaborate a little bit on that. I can't go into too much detail because there's a lot that's still, uh, in development.

But essentially to Jason's point, uh, we, we want to, uh, we're looking to make that process as automated as possible without compromising the integrity of our security model. Um, it's why it, it has taken us so long to solve the problem because it wasn't something that was easy to do and we were looking for a path forward. We have a, a path forward now.

So that's, that's, uh, in, in development. Okay, Thanks. Yep.

Any other questions? Well, I'll ask one then. Nobody else has one.

Um, you're very clearly a human oriented company, human oriented perspective, which I love. And you're now moving into machines and computer rather than humans in the identity world. There's sort of this now bifurcation of non-human versus human identities.

And you didn't touch on that, which I think is good. But I am interested sort of your perspective on that bifurcation and what it means for one password. You wanna take this or I'm happy to, I can.

Why don't you step up here so you can, Oh, I already have a mic, Don, you Step up here so people can Oh, Okay. Yeah, for sure. Although R 2D twos following, I think, oh, It's, yeah.

All right. Um, yeah, no, no. So, uh, it's, it's a really, uh, important problem to solve.

And actually we are thinking about it. Um, so for example, um, when an agentic AI needs credentials, just as, as an example of this, right? How do we actually know that that's a legitimate agentic ai?

How do we know that it's got the right entitlements? How do we know who it ties back to and all the rest of that? And so even for, you know, like credentials, it's an important aspect to be able to solve the id, uh, the identity problem.

And so it's something that we're actually actively at work on, sort of how do you model these things? How do you model the entitlements? How do you model that authentication process and all the rest of it.

But so stay tuned. Yeah, I think like everything though, we're gonna have a very human centric model when it comes to reasoning about ai. Um, I think we think these things are in service of human humanity, right?

So how do we create that linkage? The problem that we have today is you, we don't wanna be in a world where we have these AI agents sort of usurping human identities. So we can't tell if Jason did it or his bot did it.

And that's like really the first big problem to solve. We could solve that problem, be well in our way of enumerating all the other problems that really need to be solved. And that's space.

But that's like the first one that really needs to be solved right away. 'cause I'm sure there are AI bots working on other people's behalf right now, and they just show up as someone's name in an audit log, and then that person has some deniability of like, oh, I didn't actually do that. It was just sort of, it's my boss flawed doing it.

Well, no, we have to figure out that story there, and it will, it will be figured out, and we wanna be a part of that story, uh, a part of the, the solution. But it's, it's early days. It's still very early days.

Yeah. There, there's actually an example of this, uh, in the internet, like for browser use style agentic, ai, CloudFlare, and browser base, a company actually recently announced a partnership on how to identify a browser use style agentic AI versus like a person, right? Otherwise it's just detected as a bot.

And you know, it's, it's, uh, it could be like a denial of service attack or something like that, right? And so there's, there's sort of like approaches all over the place. But yeah, we definitely need to get into that, uh, that space where it's clear, right?

Okay, this is an agenda ai, this is how it's identified. This is who's agenda ai, it's on behalf of, and, and so on and so on.