# Securing Agentic Workflows: 1Password's Zero-Trust Strategy

**Podcast:** Dev Interrupted
**Published:** 2026-08-25

## Transcript

Welcome back to Dev Interrupted, brought to you by Linear B.
My guest today is Nancy Wang, the CTO at 1Password.
And like many of her CTO peers, she's building again.
In fact, her engineering team even assigns her JIRA tickets now.
We dive into how to balance this kind of productivity and why 1Password's newest developments turn even unfamiliar support reps into code builders.
But coding agents are only one part of the AI enablement puzzle we discuss.
She explains that AI made writing code cheap and pushed the cost downstream into review, security audit, and rework.
How do you build securely and safely with agents at scale on a team as security conscious as one password?
You're about to find out in my conversation with Nancy.
Nancy, welcome to Dev Interrupted.
Hey, thanks so much for having me.
We're really excited to have you.
There's a big world underneath 1Password and all of the stuff you've been working on, especially in the last few months.
I know even in particular in the month of June, you all had a hackathon that brought a lot of developers into the space to be working on different things in your new developer tooling world.
And part of that really comes true as part of what 1Password focuses on is that, you know, making security tools a delight to use.
I think that's really critical for adoption and for...
people to be able to use these tools in mass.
And, you know, actually recently we had OWASP Hacker of the Year, Tanya Janka, on the show.
She put together the OWASP Top 10 for the last year.
Oh, yeah.
I mean, she's a legend.
Yeah, she's amazing.
She's been on the show a few times.
We're really good friends with Tanya here.
And she reminded us that developers are like water.
They'll just flow around you.
So I want to hear from you, Nancy.
What do you think is the most impactful change an engineering leader can make to pull security into a golden path?
Yeah, well, you know, so no surprise, my answer is going to be related around, you know, past keys and credentials.
And actually, this is really exemplified by, for example, one of our first launches that we did with an AI native company, which is Cursor, end of last year, which is Cursor Hooks, right?
And the reason why that was so important, especially even for our own engineering team building it, was this mindset of, well, you don't need to sort of, you know, put out a PR, wait for security to do the check.
now security becomes a check within your CI, right?
Or you can do something like a postscript, for example.
And that's kind of what we're hearing from customers as well, which is actually making engineering faster because you have the right security controls from the get-go, which can sound a little bit counterintuitive.
But maybe I can share a customer example that we have from Oracle Red Bull, right?
Where they use 1Password, they use us as a centralized secrets management store.
Then they use the Kubernetes operator and Kinect server to be able to inject Kubernetes secrets at runtime, right?
In running processes, never on disk.
It's not in a .m file somewhere where you can just find it, right?
And it actually reduced, and this is a cool part because I know there's probably a lot of F1 fans listening to this episode.
And so Oracle Red Bull actually has a very large tech team, engineering team supporting all of the sort of things like wind tunnel recovery workflow, which is what they used this use case for, but also just how are they racing, how they're doing trial runs.
I mean, it's really like a systems engineering problem, which actually makes it so cool for me to just watch this all at play.
But essentially what they did, used us to inject Kubernetes secrets at runtime.
And because of that, they were able to reduce a WinTumble recovery workflow from something like 60 minutes to less than like five minutes, right, with an Ansible run deck playbook.
And so the thing here, right, and this is just one of many examples, you know, that we can share from our customers, is that the best security tool, it's not a checkpoint.
It actually removes things like weird workarounds.
And it lets your engineers keep on working.
And that is kind of what we say in our mantra here, which is let the paved path be the easiest and the fastest path.
Yeah, absolutely.
I think that's the secret to moving fast is to reevaluating the things that you've been carrying into your current workflow from the past.
And that includes actually a lot of our like rituals and procedures and process around how we build things and how we do them with agents as well.
And so in order to do it securely, you want to think about like, How can I make security something that isn't an obstacle for my agents and my developers, but is something that's just intuitive and in fact delivers results faster?
Because by baking it in on like a more deep level, like what you're saying is like injecting it into Kubernetes environments, right?
Like it's part of the orchestration, the architecture of the system.
It was not bolted on afterwards.
Security was a first class concern from the beginning.
And that's what actually.
facilitated the speed of that development.
And so, you know, speed, I think, is something that engineers and engineering leaders are really critically hinged on, kind of even obsessed with a little bit right now is we're all going really fast.
And we don't want to go fast without compromising ourselves.
And so as like an engineering leader, what kinds of like opportunities and concerns are like first in mind for you?
When, you know, you're delivering these kinds of workflows that are enabling teams like Oracle Red Bull to do what they do, like, how do we let them operate safely?
Yeah.
So this goes into, you know, some of the newer items that we've had on the roadmap.
And, you know, we shipped pretty recently, which really goes into, okay, so now that, you know, all of these wonderful coding agents, whether it's clock code, right, codex.
you know, Copilot, Cursor.
In fact, actually, a 1Password, we use every one of them that I just named and probably more, right, that I haven't named yet, like Cognition.
And the reason for that is, you know, we believe that as part of our mission to deliver, you know, security for coding agents and to enable sort of secure development, well, we ourselves have to be able to understand how these tools work, right?
And so...
Our special sauce and something that we dog food internally and we launch is, well, this idea around no long live secrets, right?
Because, you know, you and I were just talking about this before the show, right?
Jade Puffer, I think I got the name right, right?
It's the first ever like AI ransomware attack, right?
Fully, you know, AI enabled, but it still started from a human using stolen credentials, right?
Which got this.
agent into the system to be able to run this ransomware attack playbook.
So that means you still want to abide by the security rule that we've had forever, but it's even more critical in this world of agents, which is no long live secrets.
And so what we've recently, for example, announced in Beta, for example, is something with OpenAI Codex, which is, you know, you can, for example, install a binary that comes with your local, you know, 1Password desktop app.
And what it does is every time, let's say, Codex wants to, you know, reach across and be able to, you know, find or make a tool call, connect to a system, right?
That means we never actually have the raw secrets landing in things like prompt windows, either files, terminals, or even the model context.
And then similar to the Kubernetes example that we just talked about with Oracle Red Bull, we're only injecting the values into an authorized runtime process.
So you're letting the agent orchestrate.
It can still reason, be very creative.
The app executes.
But what we make sure is that the model itself never actually gets custody of the secret.
So I guess liken it to access without custody.
And that eliminates your risk surface area, similar to this Jade Puffer attack, where because your secrets are not lying around, it's not lying around and accessible to attackers.
Yeah.
You know, you say like long live secrets, you can't trust them.
It's really like if you can see the secret.
You can't trust it.
That's the real reality now of how our workspaces are built.
And if the secrets live in any capacity in the workspace where we can so plainly see and work with them, that's something that's taken for granted from environment setups before.
And, you know, people would just fall into old routines like, oh, you get it, ignore it, you're fine.
But now because there's so much live activity that's sitting on top of all of the files, you actually do have to fall back on like.
really these like almost like Linux first class principles.
It reminds me like a lot of like everyone's obsessed right now with the loop and loop engineering.
Everyone's trying to build all these crazy orchestration systems to do it.
And it's like at the bottom line, it's like, you know, you can just set up a system D, you can use your journal.
There's so much built in stuff in the machine because the machine's built to pipe, you know, inputs, outputs all over the place.
It's actually surprisingly tuned for it.
The same thing is true for like some of like the ideas of security, how we abstract security away from.
agents, like what you're describing, it almost makes me think of like using like GPG and encryption and keys to like transfer information and transmit it where the people viewing it and seeing it at rest, they can't actually use it unless they pass it through some sort of binary process, right?
So I think that's a really powerful primitive that the loop engineers of the world right now, the tinkerers that are building these orchestration systems are figuring out is how do I bring those secrets as close to where I need them as possible as make them as specifically scoped for the task at hand, but then also put them in like the cookie jar on the highest shelf.
Like none of the agents can reach it.
They can just simply get things out of there through a golden path.
I love that analogy, the cookie jar.
I mean, I might also be like time for my afternoon stack, but I'm going to steal it out.
Now I'm hungry.
Now I need a chocolate chip cookie.
I literally have some.
So if I could give one to you over the recording, I so would right now.
Thank you so much.
So they'd be up in the cookie jar.
They can't reach in the cookie jar.
Well, you know, that was actually like how we positioned actually another one of our recent launches, you know, continuing along this sort of theme, right, around no long-lived secrets, right, access only when you need it, right, just in time, and soon, you know, this concept of just enough as well, right?
And, you know, this is exactly why we also built our credential broker, which is, you know, Before times, you would say, hey, here's a service account.
Here, don't lose these secrets.
But now it's like, it doesn't matter what workload you are.
Once you prove your identity, you're able to, let's say, using a coding agent example, declare a slash goal.
You get exactly what the task needs.
And also then you lose access, whatever that task or that job ends.
Right.
And that's sort of the scoped access, the zero trust that we've known forever within security, but now applied to an agentic world.
Yeah.
And I also wanted to.
turn a question inward, just like with your CTO hat for a moment.
And you mentioned like your company uses a lot of tools, you use a lot of different workloads and things and you experiment a lot, your broad adoption on a lot of different surfaces.
And I'm just curious from like my perspective, like how do you think about measuring and understanding the success of those tools and evaluating them over time?
Like what matters to you in terms of like their adoption or their impact?
You know, I would say a lot of the kind of Dora and Smeis metrics are still coming into play, right?
Which is what you're literally looking for is developer productivity.
And I say that hesitantly because it's not just about the number of PRs that you put out, right?
Because, you know, code is cheap now, right?
Writing code itself has greatly reduced in terms of level of effort and barrier to entry.
Now, of course, what's become more expensive is code reviews, right?
Security reviews and even things like deployment.
Like I just actually met a startup this morning that is doing AI agents for just deployments, like your AI DevOps engineer, not to be confused with your SRE agent, which is something we're building internally, right?
But you're a DevOps engineer.
So, I mean, these all come into play because just because you can produce PRs quickly doesn't mean that you're actually shipping code.
And that's really kind of the leverage maybe piece I want to underline.
So from a CTO perspective, right?
how I measure whether these tools are effective isn't so much, hey, everybody went from generating, you know, 2.5 PRs a week to now 3.5.
Okay, that's great.
But, you know, if I were to go have a board level conversation, which I just did before this call, right, that's going to be fine.
But just like throwing a random metric out there, what does that actually mean?
Right.
And if you look at it from a business level perspective or board level perspective, it's all about, well, how is this helping you deliver?
features faster, products faster, or even more products at a higher quality bar, right?
Better.
And so, you know, some of the anecdotes that I've heard from various CTO peers has been, again, less like, you know, hey, we've gotten, you know, two or three X and PRs generated and more to, hey, we were able to do two features or three features on our backlog that wasn't even staffed.
for this quarter simply because we were able to move faster and we still kept up to our quality bar.
So things, for example, that we measure internally just to make sure that as a security company, our quality doesn't dip is obviously by default, things have to meet our end-to-end trusted execution model, which is our essentially zero-knowledge guarantee.
Every data secrets at rest, also in transit, is encrypted and we can go into the protocols and whatnot.
But every design has to meet that bar.
Now, on top of that as well, right, we also care about uptime because, you know, I come from AWS and literally it is probably Brandon and me for life is thinking about uptime, right, resiliency, right, things like failover.
And so similarly, right, for features that we are building almost entirely with agents now, they're subject to the same quality bar.
So we still measure by.
you know, at least four nines, five nines, right?
And also, you know, run it through our entire test suite, as well as manual testing to make sure that, you know, it works as intended.
So I would say if you don't compromise on your testing and quality, but you're able to, you know, drastically increase your velocity, that's really where you get the leverage from.
And that's where as a CTO, you can confidently go to your board and say, hey, I was able to deliver 2x.
right?
The type of products or the number of features that I was supposed to.
Yeah, that's an incredible playbook for a CTO because it's not just understanding the speed, but then mapping it back to deliverables, like you mentioned things around like understanding tasks and project management and the things that are in the backlog and what you're able to do more than you could before.
You have to be able to quantify and track that, understand how it moves through that world.
And then you also have to be just completely unwavering, uncompromising in your systems and your morals and your process and the things that have kept you safe.
Because the other thing you have to be thinking about is the downstream stuff.
And, you know, both sides of that story is a lot of like what we care about at Linear B as well, because, you know, the code generation is it piles up into one bottleneck of the system.
But the reality is, is that understanding the durability of that code for the long term, does it get refactored later?
Does it cause an incident?
Did we have to completely like take this back to the drawing board versus, you know, also on the other end, being able to look into things like JIRA and understand like, oh, wow, we have this huge backlog.
We have these keeping the lights on tasks we always have to do.
Look at how we found ways to automate that as part of this process.
Now you can see it end to end.
And I think that having that playbook and that strategy for tempering the speed with your quality is like the most powerful way to tell that narrative.
So I think that's a really good.
good playbook that you just gave us.
Yeah.
And there's also this concept of joy as well, right?
I know we didn't talk about that, but I mean, a lot of developers and myself included, right?
Especially when you, and there's this old adage, right?
Once you move into management and you manage more people, right?
The expectation that you spend hands-on coding actually decreases and you become more of an architect than a practitioner.
And what I'm seeing, especially across my peer community, especially with the likes of coding agents.
Like, for example, this week, I know this sounds maybe silly, but I was overjoyed when my engineering team actually assigned me JIRAs because I'm going to be building features alongside them, right?
And so just being able to see that aha moment, right, without having to be like, hey, I got to blow off, you know, CTO level meetings for the next three days so I can concentrate on specs, on actually writing the code and testing.
Now I have agents, you know, to your point, background agents.
I have remote agents actually writing the code for me.
And I obviously review the code myself and I do manual testing.
But that entire sort of uplift of sitting down, writing the code yourself, right, that's all been abstracted away by coding agents.
And so having that aha moment, be able to, frankly, like experience joy in building again, while also, you know, doing all the CTO people stuff that I got to do, like, that's fantastic.
I love to hear that, especially from you and your role.
But that's also, you know, not a weird thing to say at all, especially here on Dev Interrupted.
I think we have a lot of builders, product leaders who come on the show right now, and they're so delighted to be back in the terminal, to be building things again and to be enjoying.
Taking the craft of coding, which many of them have built and have a skill in, but have largely had to set aside for people management and becoming leaders of their large engineering orgs, for them to be able to take their systems-based mind approach of how they've built those engineering orgs and now use it to create their orchestrators or their army of agents or whatever their case may be.
It's really amazing to see what folks can do once they're agentically enabled and also to...
Like you mentioned, just being able to explore and try new things.
But with that also too, just becomes like a multiplicity of activity.
This is something that I think that we've all been living through just in great detail, in great pain, in fact, through 2026.
Like we've watched GitHub's, you know, status page just become a whole bunch of orange and yellow, especially at the top of the year when we all came back from Christmas break and everybody suddenly had an orchestrator.
happy that we have self-hosted GitHub runners.
Oh, trust me.
Everybody who had a self-hosted GitHub was like, this was what we did this for.
And so we had, you know, that, that.
Every status page that used to have all of those nines, they don't anymore.
And a lot of that has to do with just there's so much more activity on the web.
Most websites that are made now are AI generated.
Just very recently, half of all internet activity has been attributed to agents or to bots.
And so there's just a huge amount of activity.
And for folks that are building developer tools, building SaaS platforms, building things with API surfaces, they're like getting bombarded by workflows that are improper.
vetted by novice engineers who don't understand how to debounce and everything in between.
And so from your perspective, you're building tools that probably have a lot more inbound activity from all of these new agentic consumers.
How does that concretely change how you think about 1Password's architecture or how you protect your services and all of those lines that you want to protect so much as an AWS alum?
Yeah, I mean, wow.
What a pat question.
Yeah, I mean, look, we think about that a lot.
And that is why we also have other features that we've launched, like agentic autofill, where we're going to autofill for browser agents, right?
Eventually, we're going to deliver the same capability for remote agents as well.
And essentially, our mantra, right, as a company is whether you're a human, you're a machine, or you're an agent, and really, you can say human identities, non-human identities, right, to keep it simple, right?
You can access 1Password as your vault of the internet.
Right.
Where we keep your secrets safe, no matter what type of secrets they are.
And so that's why, you know, fundamentally we are designing for a world where, yeah, to your point, maybe more agents than humans or more non-human identities than human identities are actually accessing the vault.
And that's why, for example, we also made the decision recently to acquire Epono, which is a privilege access management company, because identity.
all of these scenarios, right, where more agents than humans access your vault, is it becomes a runtime problem, right?
It's no longer, hey, here's a cache of, you know, secrets.
You can copy a secret or, you know, have it auto-filled into your browser.
But this is where you have to understand, you know, who the agent is, which goes into the agent identity problem, right?
Who maybe is the human delegator to that agent?
What is the declared goal for that agent, right?
The scope of the tools they're accessing.
the TTL or maybe the time to live for that specific credential or token?
And also what policies is this agent taking action under?
Those are all like, if you think about, you know, I was just talking about this with a founder of an AI infrastructure company.
You know, this is really like a real-time decision where you had ML models, right, with feature stores.
I mean, that's classical ML theory, right, doing this decision-making.
But really, it's kind of similar to what I just described.
It's runtime, it's real-time, and you have to make a decision whether or not to grant access to that agent doing the thing on that policy at that moment or not.
And so this is where we've also thought about where kind of boundaries exist between, let's say, the user, the platform, and the vendor.
And we can probably go into that in depth as well.
But this is where I think the security, actually boundaries between the three start blurring.
Where would you start drawing those lines?
You know, I called out the novice developer a moment ago who doesn't have the basic practices or maybe is just like throwing whatever it takes and doesn't have a good harness.
You can't protect yourself that much against that person.
Like how, how, where do you draw the lines?
And then how do each of those stakeholders kind of protect that?
Yeah.
Well, that's funny.
As I was thinking about my answer to your question just now, I thought about the AWS shared ownership model.
And I can see this architecture diagram as clear as day in my head right now because literally we would go through that model all the time with our customers and EBCs because it's very similar here, right?
The customer owns the data, right?
AWS owns services or managed services like RDS or S3, et cetera, et cetera, that contain that data and obviously networking, compute, et cetera, right?
But essentially there is a line that you can draw.
Now it gets a little bit more murky because let's say, you know, you have a specific platform.
Let's say you use, you know, now these agent factories that are popping up across different companies or sandbox, right, companies.
And sure, the platform companies might own, you know, things like sandboxing, the execution.
So I think functions, right, and different boundaries between different tools.
And then maybe, let's say, a vendor like 1Password might actually own sort of how we store and protect your credentials, the different policies around when you can use them, when your agents can use them, and when they can't.
When do we issue those secrets, for example?
How do we revoke?
And that's really important as well, because once the task is done, you should revoke.
And then finally, audit.
But as you can see here, it's no longer as clean as, hey, the platform owner.
you know, owns these different substrates of storage, compute, networking, and, you know, the customer owns the data.
It's really about like who owns sort of the underlying platform and who owns a runtime, right?
That I see as sort of the separation of responsibilities.
Yeah.
And when you start drawing the lines like that too, it really becomes like understanding.
Like the guardrails that you need to have in place as an individual developer, but then also the golden path systems you have to make to make sure that those movements between those stakeholders, the vendors that you use to build your product and your engineers that are building your product and delivering it, that there's this, you know, coexistence in terms of like your data policy, your security, and also making these decisions like.
In an instant, like you're talking about scaling and having huge amounts of interactions, inbound activity that you have to scan for.
You have to like screen again suspicious activity while you're simultaneously trying to authenticate.
And then there's the whole matter of like trying to actually like load balance this whole thing across the whole globe.
Right.
So it's a large engineering challenge.
But what makes it even harder is that you'd like make a.
almost like a snap decision.
Like in a moment, you have to decide, does this agent delegated this person for this scoped task, get this.
And you have to have a system that can have an instant response so it doesn't block things like Oracle Red Bull who are trying to go fast and build things, you know, really build a wind tunnel.
You don't want to be blocked.
You don't want to be blocking the wind tunnel time optimization.
And so like because of that, like it goes back to what you said at the beginning about making the golden path, the easiest path making the golden path makes everything faster.
But Two, it just makes me think of like these gates that decide in a moment.
How do you think about them in a determinism aspect in terms of a probabilistic aspect?
Is this like an agent making a decision in real time?
Probably not.
It's probably a whole bunch of mechanical guardrails.
Like how do you fall back on that idea?
Yeah, I mean, that's absolutely right.
In fact, one of the upcoming reports that our security team is going to publish is really like a harness that we've also built internally that our product security team.
This was able to distill, I think, over 300 different security rules that we've used since the beginning of 1Password into an AI-assisted review program, or we call it our security harness, right?
And why that's really important for us on the engineering team is we're not sort of then waiting on tickets from the AppSec team that review code.
We're able to actually build that furnace into our code review process.
And so, again, reduces that time to value, and that's really what we're focusing on.
Wow.
Okay.
So security is a loop now and it has a harness and there's a flow that you can go through and there's steps that all those stakeholders can do at every stage of those of that circular flow to be good inputs for the next.
And it becomes a virtuous system.
It's kind of interesting how...
It's self-learning, self-healing, and then that perfectly becomes adaptive to these things like software factories that you mentioned a moment ago that it's a very trendy topic right now.
Everyone is very obsessed with trying to figure out how do we create that kind of end-to-end loop.
And I think understanding the determinism gates along the way and being able to split things into lanes and measure all of that activity is going to be the most effective way to get a grasp on it.
Also just having good log.
It goes back to just like good fundamentals.
We talk about that a lot on Dev Interrupted that like right now, oh, how can I just get really ahead in an agentic world?
Well, you know, eat your Wheaties, like do your eat your breakfast, do your homework.
Like you need that.
You need to have clear communication process because like building software is a contact sport.
We got to communicate with each other.
And if you don't have the processes in place to facilitate that, then you're not going to go much faster or much safer with agents.
Exactly.
And I mean, that's where you don't throw the old textbooks out the window, right?
Now is exactly the right time to do zero trust.
Now is exactly the right time to do identity verification, right?
Now is the right time to go.
Make sure that you have golden copies of your sensitive data stored in like Fort Knox somewhere.
So when you're ransom, you have, you know, golden copies to recover your business data from.
So those definitely still exist.
And which is why now maybe speaking from a business perspective is if you look at, for example, what companies have done really well, especially in this AI transformation age is actually still the companies like the infra companies, right?
The middleware companies that we continue using like Twilio, for example.
I mean, they've went, you know, Crazy in terms of growth, right?
The storage companies, because look, agents access file systems.
I mean, as an infra nerd and builder, like it makes me really happy that I guess I'm not super irrelevant in this day and age.
A new hire's first mistake used to be doing something wrong with Git.
Now it's an AI slot pull request merged straight into main from an untamed agent.
But the accountability should be the same.
You should own the code that you ship, whether you wrote it or generated it.
As AI writes more of your code, it's more important than ever to have strong checks and balances in place.
Without them, security risks and spec mismatches slip straight into production.
Linear B provides policy-driven AI code review that catches risks and enforces your standards before human review even begins.
Govern your AI workflows without slowing your team down.
Learn more at linearb.io.
Yeah, agents want to use security tools.
They want to be secure.
People want to build secure workflows.
And so it's only just going to become more fuel for more things that get built as people become more agentic.
And, you know, speaking of everyone becoming more agentic and everyone right now is figuring out how they can lead their engineering teams into that agentic engineering world.
I want to take a moment also to.
revisit something like the builder hat you've been putting on lately.
And it sounds really exciting.
I know too that in the developer world of 1Password, y'all just had so much tooling and releases that have come out very recently.
And you had a whole month hackathon as well, where folks built a whole bunch of stuff on top of your platform.
You know, I'm just curious from your perspective as like a CTO in that role, how do you focus on moving quickly, but also then?
preserving the brand around we are deep on privacy and trust.
And yes, it's safe to build an experiment and be agentic, but you can be secure at the same time.
I think leading with that message is it can be, you know, it can be really hard for folks to strike the right balance.
Yeah, for sure.
In fact, actually, you know, real real data points is when we released our blog and this was probably a few months ago around using.
cursor agents to help us refactor the monolith.
Well, that was really important because, you know, agents actually helped us probably refactor 50 to 60% faster by being able to actually crawl the entire code base much faster than a human could.
And it actually made pretty good suggestions on which endpoints we could pull out first, right?
And which sort of data models were kind of so entangled with those endpoints that as we were factored and were able to pull out separate microservices, you know, in what order should we pull out those microservices?
And because, you know, their recommendations were actually pretty good because it was able to crawl the entire code base.
You know, we've since now pulled out two or maybe three services now, endpoints completely out of the monolith, which has, you know, helped obviously free up headroom because our, as we get more customers, right, the number and the volume of queries per second also goes up.
So we want to be able to serve that traffic in a good way, right?
Going back to, again, resiliency, availability, uptime signals.
And so that obviously led to some conversation, of course, in the community of, well, is 1Password just letting our agents then or letting your agents see our credentials, right?
And so that's where, you know, we had to do some explaining to do, which is, look, agents can't see your credentials.
Why?
Because we can't see your credentials.
That's why it's zero knowledge.
Right.
Your credentials, frankly, if first I can't log into your vault because it needs it's an asymmetric key encryption.
Right.
Only you have your private key.
I might have your public key, but if I don't have your private key, it's still no op.
And let's say even if we were able to get in or someone used your private key because they were on your device, what we see is actually encrypted blobs.
Right.
And so that's the level of security guarantee that we do not compromise on no matter what feature we build.
whether it's with humans manually writing code or with agents doing, you know, coding loops, right?
So that's things that we will just not compromise on.
Also things like cryptography, right?
A lot of our cryptography is still very manual because again, this goes way above my knowledge here, right?
But in terms of how we design the protocols, how we guarantee safety and security, right?
We never want to compromise that.
And so this also becomes a conversation around, well, where do you enable full agent loops?
And so those naturally are going to be largely front-end heavy features, for example, because agents are a lot faster in building UI, right?
Or things that require heavy security architecture, security models, many of that or most of that actually still require a human in the loop, right?
So this is where we just have to be very deliberate around when and when not to use it.
Right.
So does that come down to like measuring and under or like rather like labeling and delineating that work?
You mentioned like security reviews.
And so having a system by which like the work that moves through our engineering org, we can identify it, maybe even tag it and then do different types of work depending on the level of human attention or mediated help that it needs.
Is that kind of what you're working towards?
Yeah.
Right.
So similar to how you would have like, you know, story points, right, for this is a harder to implement versus.
easier to implement.
There's also tagging, to your point, classification involved.
And largely, I think this is how I think about agents is they're best when you use them to automate deterministic toil.
So things like where you can easily test success and you can easily do rollbacks, those are great candidates.
But when it comes to, for example, ambiguous judgment, things like building this policy engine that does just-in-time determinations, keep the human in the loop.
Right.
Anything that is production systems, we definitely have to keep the human in the loop.
You require a human operator to review and sign off on any changes that go into, for example, our core repo.
Right.
Also understanding things like, you know, customer trust boundaries, because that's also really important for us.
And anything that, you know, using Amazon terminology is a one way door.
Right.
Once you go through, you can't easily come back.
So it's really this, you know, kind of sliding scale of the more sensitive the decision or the system that you're taking the action on.
Right.
You have to just be way more explicit with like the spec and also the escalation path for a human.
Yeah, this becomes a really powerful lens, too, for the playbook you gave us earlier, because by doing this labeling and understanding the level of attention that you need, then you're able to then a better route.
that work.
But then also, too, when you look at your AI uplift, like we go back to those charts like, oh, we're having X number of more PRs.
We're writing the X number more lines of code or whatever the case may be.
And you see that lift, that trend in the graph.
If you can map some of that to those kinds of recurring story point ideas that are small or very modular, easy to break apart and make repeatable and you can trace that, then that becomes like a really powerful way of being like, yes, this is a durable practice.
that we're building.
Cause like you just identified some really great candidates there.
You know, we've talked a lot about on the show too, about people transforming like really old architectural or doing mass migrations of like run times and stuff, especially on like really large platforms.
And this is largely something that like you said, can be heavily tested and rolled back and can be very systematically done.
It's about creating just the system that can, that can do it.
It just needs someone to put in some initial investment.
Right.
And so.
Creating those systems is what gives you that durable long-term lift.
I think that's really, really insightful.
And the opposite side of that coin too, I'm curious about is like...
Something that's really trendy right now, too, you talked about like software factories and stuff.
Also companies going with like the idea of token maxing, like just use as many tokens as possible, consume as much as through your API as possible.
Like, what is your thought on token maxing?
Obviously, that runs antithesis to some of the things you've covered today.
So like, how do you prevent that kind of mentality within like an engineering org?
Well, so first off, we're not putting caps yet on token spend.
And I'm laughing because we have a Slack channel called AI Guild, where all the developers that are using our tools hang out.
And I think one person just said, hey, am I allowed to use Fable now?
I know it's very expensive.
And I just thought to respond, but I'm like, you know, let the community maybe take this one.
Also, I don't want to be, you know, that person.
that comes in and, you know, turns the lights on at a disco party, right?
So it's okay.
So I'll kind of let them figure it out.
Well, you're welcome, AI board, that I pulled her away right before she dropped the message in and dropped in here, you know?
Exactly.
But look, it comes back to, you know, the same thesis around...
you can't just measure productivity by how many PRs you generate, right?
Maybe you're generating like five two-line PRs, maybe because it's a bunch of bug fixes, or maybe you're generating like one, you know, half a million lines of code PR, right?
Because you're building this massive feature.
So just like not every PR is created equal, right?
Not every token is being spent on equally useful things.
And so this is where, you know, we do have a leaderboard internally of who are the top spenders.
And so far, I mean, you know, I will...
manually pick out anomalies, but they also align with the engineers who are delivering the most work, right?
Most features, most products, most platform changes.
And so rough and tumble, it kind of matches out.
Now, I think what's going to be really interesting, and this is something we're also building, is if you're able to tie spend for these various AI tools to productivity, right?
Because that's eventually not just what...
CTOs need to know because we have budgets that we need to measure against or manage against, but also your CFO, right?
So that they understand like, hey, where is all this money going, right?
Because not only do you now have fixed costs in terms of human headcount, which is usually, was actually the biggest spend target, right?
Now you also have variable spend or operating costs from the usage of AI tooling.
And what's netting out, right?
Are we in the positive?
Are we not in the positive?
Yeah, this is a huge part of all of the things we've been talking about today and as part of like what people would even use a tool like ours to try to figure out, right?
Because you do have these variable and fixed costs.
They have different levels of accuracy and throughput.
through your security, through your like your entire SDLC, right?
And so because of those two factors, it's really complex to get a grapple on it.
You need a place that centralizes like this is all of our API costs through cloud code.
This is our subscription costs.
These are our seats on cursor.
And then for those same users being able to understand like, oh, and then these are the PRs they're doing.
Like you go back to your token maxing board and you talk about like the high performers and like sure they're at the top of the list, but they're also having.
huge impact.
And so it's amazing to put them there and to identify what's working.
Right.
And I think that comes to to understanding probably like if there is that uplift of AI adoption and it's durable and you're getting results and you're able to attribute those.
you know, those story points we talked about earlier to those durable downstream things, then identifying, oh, did you create a system that did this at scale?
Did you migrate something?
What you find is that like, oh, that person on that leaderboard, they represent these large scale projects or automations or things that they've managed to architect.
And so now the learning opportunity becomes how do I...
share this expertise with the whole organization?
How do I turn this thousand X developer into a 10X everybody is what we've been saying around here.
And so distributing those gains, I'm curious to like how you think about using those signals to drive the change.
Yeah, I mean, this goes into actually some of the updates that we've made in our interview.
Loop, for example, what we usually test for, we no longer do coding tests, is actually agent.
builder test, actually, where I ask to see your prompts, your test cases, and I progressively ask for harder test cases.
And this goes back to really good engineers.
The best ones that I know are really systems thinkers.
And this is something that was really drilled into us, whether, and I actually worked at Google as well prior to AWS, also building infrastructure systems.
This is where that comes.
back into the picture in tenfold, right?
Because things like state management, right?
State machines, be able to retry, retry logic, failbacks, right?
Agents are just workflows, right?
That reason, right?
In between different steps.
So they don't take always the next step after, you know, it's not a sort of dependable, you know, four-while loop, right?
So this is where, you know, you have to have strong specs, right?
You have to have strong tests.
And, you know, being able to be literate around evals.
I find that's probably the still, you know, maybe the hardest hurdle for many engineers who are in that sort of AI transformation process is understanding what is an eval, first of all, and also how do I write good evals so that my agents that I'm actually running in production, I know if they're working or not working.
I love this interview format, this idea of flipping almost like the coding exam.
And realizing that like what we used to stare at and focus at is that the code creation during those whatever time period and evaluate how it was done, how they thought through it.
Now it's like you cut that out.
What's around it?
How do they think about the planning and then actually lining up the systems to be done?
How do they define what was good?
What were the constraints?
And actually understand like what would success versus failure look like and eliminate those things before even starting to build.
And then being able to.
to meet the test that we put to the fire a little bit of like, how well do you understand this system that you put together?
Something you're proposing, which by the way, within an engineering org, when you're building and proposing systems within a product, like there's a lot at stakes.
You need to understand the stakeholders and the downstream impacts and the stakes are much higher.
So being able to screen for that level of not only taste and execution on the systems thinking level, but also just like the impact thinking as an engineer, because I think engineers right now.
It's like the biggest challenge is how do I get as close as possible to the customer problem?
And how do I get literate in what my customers or what my users are most deeply concerned about?
And traditionally, all of the barriers between them and that conversation were so, so much.
You had the CSMs and the account execs and the product marketing team and the product team and then everyone else before you would start to think like the engineers and getting them close to that problem.
But now.
All of those people in between have some element of engineering and engineering has extended all the way into all of those organizations.
The engineer actually has somebody to walk all the way up to the customer, look the customer right in the face, be part of the conversation.
And I think that's so exciting for builders and being able to screen for the builders that are not only see that opportunity and want to walk all the way up to that conversation and be a contributor and sit at the table, but then also think then, how do I build things that are going to make?
an amazing experience for this user.
It's going to protect them.
In your case, keep them safe.
Right.
And that's actually, you know, maybe a great segue to share one of actually the more exciting experiments that we're running this quarter is actually.
Who is a builder, right, within one password?
And sure, you know, the usual suspects of engineering and you have some, you know, technical PMs and designers who are also builders.
But now, for the first time, we're actually expanding that designation of essentially who's able to write code and then check in code to customer support reps.
And the reason why that is so important is, you know, as a, we also have a fairly large consumer business where our consumers, you know, they're using our browser extension fairly daily, our desktop app.
And for many consumer users, they're also developers or hobbyist developers.
So they're using our CLI, our SDK, and they're the first ones to report if something is flaky or buggy or, you know, the modal might be off on the UI or whatnot.
And so when CSMs get that.
Typically, it gets routed into engineering.
Engineering has to look at the backlog and say, okay, we can maybe take care of it in this sprint or in this other sprint.
And that's a pretty long time, right?
Versus if we empower the CSMs with coding agents, right?
Like the ones we just talked about, and also build them a safe factory in which they can run their own tests, set up their own, you know, dev environments, right?
To run their code through, right?
and we can enable them to ship code, right?
That's going to be the holy grail of unlock for all of the customer support tickets that we get in.
Yeah, that's a huge leverage.
Actually, that's such an amazing point.
Very recently, we had a new segment on the show with...
with one of our friends of the show, Kelly Vaughn, and she wrote an article recently about that exact thing, about how if you, you know, you can create this safe environment that can prevent one, a backlog from even happening, and that too, it can empower these CSMs, these folks that are close to these customer pain points that are always having problems hearing things directly from the customer, want to be able to directly enable and fix them, to be able to actually make that change without having to fight for space on a roadmap.
It's like fundamentally orthogonal to what they're trying to say.
solve.
So now they can finally get to the heart of it.
And I think that's like one of the many unlocks that that engineering leaders can really find within their org now.
And, you know, I got to say, Nancy, you've given us like a lot of I've said playbooks.
recipes, menus, like all like routes, like all sorts of ways to think about navigating this world.
And I just really want to thank you so much for joining us and sharing your security minded perspective.
And I think it's a really helpful reminder for all of us that you can not compromise on your values and what makes your product durable and safe for others, but you can still be agentic and you can still be on the cutting edge.
And there's so much that's coming out of one password right now.
Just as we wrap up, where can our audience go to learn more about like the latest and what's coming next?
Yeah, check us out on the website and especially 1password.dev is our new dev website.
So if you want to understand, you know, what's new and hot, right, coming from 1password as a builder, as a developer, you know, check us out.
We're also going to be doing a lot more sort of demo style videos from our technical marketing team.
So you can see, for example, one that I just reviewed is how do we discover some of the secrets that are lying on disk, right, through the app and be able to vault them or protect them with one password vaults.
And so that's an example of something that, you know, it's going to be, I'm really excited for it to come out and be truly game changing.
Yeah, that's awesome.
So we'll make sure those get in our show notes so our listeners can go and follow those.
And to those listening, you know, if you've enjoyed our conversation, please come and find Nancy and I on LinkedIn or Substack where this newsletter accompanying this podcast is also published.
And if you made it this far, you clearly liked it.
So give us a like, you know, maybe subscribe, listen to the next one as well.
Give us a review.
But more importantly, come and find us and join the conversation.
You know, I think we're all better builders right now if we can share best practices and build more openly.
So thanks again for joining us.
And Nancy, I really appreciate, again, joining us to chat on the show.
It was a ton of fun, and I can't wait to have you back sometime.
Thanks so much for having me, Andrew.