Twenty-four million secrets were leaked via GitHub in a single year. As organizations scale across multiple clouds, microservices, and AI-driven workflows, the challenge of managing API keys, tokens, and credentials is only getting harder.
Amber Britton is the CEO of Doppler, a centralized secrets management platform built with a developer-first philosophy. Before joining Doppler, Britton spent a decade in the tech startup space, split between cybersecurity and MarTech. Under her leadership, Doppler has focused on meeting developers where they work, with CLI tools, code editor integrations, and a recently launched MCP server for AI-assisted development.
Expert Insights spoke to Britton about why secrets sprawl remains one of the most underestimated risks in cybersecurity, how organizations should be thinking about non-human identities and AI agents, and why the tools that win are the ones developers actually want to use.
Watch the full episode below, or listen on Apple Podcasts.
Q. Could you give us an introduction to yourself and an overview of Doppler, what the platform does, and what sets it apart in the secrets management space?
I’m Amber, CEO of Doppler. I’ve been in the tech startup space for about 10 years, five of that in cybersecurity and five earlier in more of the MarTech world.
At its core, Doppler is a centralized secrets management platform. And what I mean by secrets are things like API keys, database credentials, tokens, the kind of data that powers every modern application. The challenge around secrets is that they typically end up all over the place. Hard coded, scattered across different .ENV files, copy pasted. We call that secrets sprawl. And it’s one of the leading causes of breaches today.
Doppler is set apart in the space by being very developer first. We really consider ourselves as a tool that was built for developers first before anything else. Most security tools are built for security teams to use them. They’re really powerful but often end up being really complex to actually deploy or to use. And then they’re kind of painful to adopt. We realized early on that if security tooling isn’t something developers actually like using, it doesn’t matter how secure it is, they aren’t going to use it. They will find a way around it.
So, we built something that meets developers where they work. That shows up in a bunch of ways through our CLI, our code editor integrations, our full API and webhooks, deep integrations with all the tools that they use. So GitHub, AWS, Kubernetes, etc. Even our newer MCP server for AI-assisted development. They don’t have to change how they work to start using Doppler. We just fit into the tools that they’re already using.
That results in engineering and security teams being able to centralize their secrets in one place and enforce access controls and automate rotation of those credentials. Security teams get a nice audit trail of all of that. And you don’t have to grind your developer velocity to a halt in the process.
Q. What are the risks that teams face when it comes to managing credentials, API keys, and sensitive configuration data across .ENV environments? Why is secrets sprawl such a growing issue?
First, if we talk about the scale of the problem, it’s really staggering when you look at some of the data. GitGuardian does a report every year, their state of secrets sprawl. I believe it was their report for 2025 that found something like 24 million secrets had been leaked via GitHub in a single year. That was a 25% increase year over year. And the large majority of those secrets had first been detected three years ago and were still active. That’s a three-year window of exposure for credentials that were never cleaned up.
The risks break down in a few ways. The first and foremost is visibility. Most organizations do not know where all of their secrets live. They’re all over the place if you’re not using a solution. .ENV files, they might be in Slack messages, they’re in tickets, they’re in old repos. It’s very much impossible to protect what you can’t see. You first have to really understand the scope of the problem internally.
The second is over privilege. There’s research that shows the large majority of non-human identities, like bots, service accounts, have excessive permissions. So if one of those gets compromised, the blast radius is really enormous.
The third risk category is rotation, or really the lack thereof. A huge majority of machine credentials and non-human identities are just never rotated. So if a secret is compromised, it stays valid indefinitely until you find it or are forced to rotate it.
There’s another risk that gets overlooked a lot, and that’s offboarding. When an engineer leaves your company, what happens? It’s good for security professionals to ask themselves: do their credentials get rotated? How quickly? If you don’t have a centralized secrets manager, the honest answer you would most likely hear is never, or slowly, if you don’t want to admit never.
A former employee that has an API key that’s shared with the rest of the team, that is a real risk. That is an open back door. With a secrets manager, especially one like Doppler, you can immediately revoke access and rotate any affected credentials the moment you’re offboarding someone, or even a contractor. That instant provisioning and deprovisioning is something you just can’t do reliably if your secrets are scattered across individual machines or different files.
And the pace of modern development makes all of this worse. Teams are spinning up microservices, deploying to multiple cloud providers, building with third-party APIs. You add AI into the mix. The attack surface is just expanding faster than anyone can keep up. That is why we continue to see breaches at organizations like Dropbox and Oracle and even the US government. Often they are traced back to a single leaked or unmanaged credential. That’s a huge business risk. And it’s one that is getting worse.
Q. The rise of agentic AI and automation is creating a new category of machine identities that can generate requests and rotate secrets at scale. How should teams be thinking about secrets management in the world of AI?
It’s a great question and I think it’s one of the most important shifts that’s happening right now in software development, especially in cybersecurity. I don’t think a lot of organizations are ready for it. Smaller organizations are more capable of being ready for it and more on top of things, but still not perfect. Larger organizations definitely aren’t ready for it.
For non-human identities, we’re talking about AI agents or bots, service accounts, that kind of thing. They are outnumbering human identities. Something like 144 to 1one or 100a hundred to 1one. And that number grew just in the last year even more. That ratio used to be unthinkable. Now it’s the reality that teams are operating in.
The challenge with agentic AI specifically is speed. You’ve got a human developer, probably able to generate a handful of API calls in a day. But an autonomous AI agent can spin up, request credentials, complete a task, rotate hundreds of tokens, hundreds of times an hour. The manual way of doing it just doesn’t work at that velocity anymore.
That means teams need to be thinking about the layer of trust and privilege at every identity layer, whether it’s machine or human. Every agent, every service, every automation needs to get the minimum privileges it needs, scoped tightly wherever possible, rotated aggressively. You also need visibility from an audit perspective into what it’s doing. If an AI agent starts behaving unexpectedly with the access it has, you need to be able to catch that really quickly. And you also need to know what happened up to that point so you can have that trail to follow.
At Doppler, we really see this as a central challenge over the next couple of years. The organizations that spend time now building out a strong foundation of centralizing their secrets and enforcing access and automating rotation, are going to be the companies that can really confidently adopt AI tooling over time without adding enormous hidden risk.
Because even though a team isn’t blessing adopting AI tooling, team members are adopting it. And so you need to be able to control that. Start building that foundation and those policies now.
Q. If organizations build those policies, could that lead to a more secure future where secrets management is embedded early on and outcomes improve over time? Or are you more concerned that AI will introduce different vulnerabilities?
With AI, definitely there will be different vulnerabilities that come up, for sure. I don’t think that’s necessarily pessimistic, but it’s a reality. If you don’t already have a foundation of secrets management, you’re just playing from behind. Building that foundation now means you’re much better suited for any new threat that comes up. But if you don’t have that first, you’ve really got to start from the basics.
AI is not going away. Microsoft Excel did not go away. Google Docs and all of these tools that we now just use and don’t think about used to be novel and new. People were threatened by a lot of this automation. AI is another one of those.
Some of us, myself included, can feel the AI overload. Every tool is talking about AI and it’s not always valuable or even a real good use case. But it’s definitely a skillset. There are really strong tools in software development that use AI that are not going away. It’s going to be a skillset that people are expected to know and expected to interact with. Companies are trying to do more with less and AI helps them do that.
You need to be able to control what those tools have access to. Because if you don’t, it really is unfettered access that you’re just provisioning if you’re not thinking about it.
Q. You mentioned smaller organizations might be able to be more agile with AI than larger enterprises. Could you talk more about that paradox, where you might think a larger organization would have the resources to do it properly, but that’s not always the case?
It’s definitely a reason that I like the tech startup space. Larger organizations, as you get bigger, you get more policies in place and more red tape. Things take longer to change and things take longer to implement. That’s where you see people complaining about needing all these layers of approval to do something so simple. That’s because the business has more risk. As you get bigger, you implement these policies so you don’t introduce unnecessary risk. That means when you’re trying to adopt a new tool or change a process, it has to go through all of these layers of approval. It’s for a reason, but it means that organization is slower.
There are certain sectors where this is really pronounced. Healthcare is a really good example. When I look at a lot of healthcare tools, you just feel like you’re in the stone age. Why aren’t they doing something more modern? It’s because of all of the compliance they have to adhere to and all of the red tape of things that need approved. It takes them longer to change to something more modern or to adopt a new process.
It’s much easier and more nimble for a smaller company that doesn’t have all of that red tape. They don’t have layers and layers of people to ask. You can adopt tools and technology a lot faster at a smaller org because you just don’t have those layers yet. As you get bigger, that changes and organizations go through that pain. It’s for a reason, but it’s what makes it easier for a smaller company to move quicker.
Q. Compliance frameworks like SOC 2, ISO 27001, and HIPAA are tightening expectations around how engineers handle credentials and sensitive data. How does centralized secrets management help teams with their compliance requirements?
Compliance is actually one of the areas where it’s easiest to make a case for centralizing secrets management because there can be audit requirements that map almost directly onto the capabilities. It’s also important to note there’s not yet a standard compliance requirement around secrets management. NIST has a framework and a requirement around password management, but secrets management is still in an early adoption phase. It’s moving very quickly, especially in the last couple of years. It’s a matter of time before it is a clear, hard requirement. But it doesn’t mean organizations don’t set their own requirements. With ISO, you can set your own business policy that you’re going to have secrets rotated on a certain time frame. Some companies have early adopted it and some security teams care a lot about it.
SOC 2 is a good example. When you’re getting audited, auditors want to see access controls. They want to see logs. They want to see evidence of least privilege. With a secrets manager like Doppler, every access event is logged. Every permission is configurable and you can have an audit trail that shows any secret and what happened at any point in time.
Those logs don’t just live in our product. You can export them into whatever observability tooling your security team is using. Datadog, Splunk, or through our webhooks, you can send them wherever you want. Your security team has that full audit trail in the tool they already live in. If you compare that to a world without a secrets manager where secrets are scattered all over the place, even if nothing bad happened, you can’t prove it. You can’t just tell your auditors that you think it was fine, because that doesn’t pass. You need proof. You need a screenshot. You need something.
HIPAA, ISO, GDPR, they all have similar requirements around access to sensitive configuration data. And there are some really strong penalties for failing those. The common thread of what auditors want to see is intentionality. They want to see you made a conscious decision about who can access what, that those decisions are enforced, especially if they’re enforced programmatically, and that you have records.
Without that, best case scenario you spend a lot of time scrambling before an audit starts to reconstruct a picture of the access controls that should have been there all along. Worst case, you fail the audit, which has a massive cost. Or you face financial penalties. Those GDPR fines are not cheap. Or you discover during the process that you have exposures you didn’t know about.
We’ve seen organizations go through that exact painful experience. That’s usually the moment they decide to prioritize secrets management and come to Doppler. The good news is that there are platforms like Doppler that can essentially operationalize that compliance for engineering and security teams. The controls are just built in. We’re not adding them on after the fact. It’s just part of the product.
Q. Doppler has always taken a very developer-focused approach and tried to make the experience as easy as possible. Can you tell us more about the importance of developer experience in secrets management and how that has shaped the way your team has built the product?
I’ll also say for this audience, most anyone listening will know what a secrets manager is. But for those that don’t, password management is a really great analogy to help someone understand it. My parents have no idea what Doppler does or what I do. The way I give them an analogy is that it’s like a password manager for engineers building software. It’s a really good comparison.
I feel really strongly about this because I think it is the core insight that separates the tools that people will use from the tools that are just going to sit there collecting dust. We have all bought software that has just sat unused. I have one example in my mind of a software that we purchased at Doppler last summer that we have yet to operationalize because it’s way too difficult and doesn’t solve the problem the way we thought it does. We’re just not going to renew that.
It is a problem and you see more and more teams trying to operationalize with fewer tools because they’re realizing they’re buying too much. With security tooling, you can build the most technically secure products in the world, but if developers find it painful to use, they are going to route around it. They are going to use .ENV files, they’re going to hard code things in a pinch. They’re going to find a way around it because they are very inventive, very creative. If you’re focusing on developer velocity for your own software and pushing your team to keep building, velocity is going to lose out to friction at every point. It’s not because they don’t care about security, but because you’re pushing them for something else.
For us, developer experience is not a nice to have. It’s been our strategy. If we are easier to use than the alternative, not only an alternative secrets manager but just the alternative of .ENV files or doing it manually, developers are going to choose the easier solution, which is us. That’s how you shift behavior at scale. We have had teams that built a whole homegrown secrets manager themselves that just realize the cost of maintaining it and staying up to date is too much and it’s affecting their own velocity.
We’re meeting developers where they already work. Our CLI, our code editor integrations so secrets are right there within your editor and you don’t have to context switch. A full API and webhooks so teams that want to build their own workflows can do that. Our recent MCP server that lets you access and interact with Doppler in a natural language kind of way if you’re using an AI coding tool. Deep integrations with the services teams are already using. Every interface you’re already using, it just works wherever you need it.
We actually extend that, not just into the core of our product, but into our pricing and plans and entry points. Developers want to try tools out. They want to get in there and try it. You do not want to talk to a sales team to use a platform as an engineer. Individual developers can use Doppler for free. I’m very passionate about that. That is never going to change. We will always have a free entry point, no time limit, no credit card required. Go in, kick the tires, check out the platform, see the value, and then use it for your side project or as a student or a really small team. Usually you’re seeing the value and then bringing it to your team. That word of mouth, bottom-up adoption, that is how we’ve gotten to where we are with huge companies using us. But it only works if the product makes developers’ lives easier. That has been our secret sauce.
We hear a lot from teams looking at switching from something like a HashiCorp Vault. Incredible tool, very powerful, but it often requires a dedicated team or person to invest the time in setting up, maintaining, and running. Our pitch is that you shouldn’t need infrastructure to manage secrets. We will handle that. You focus on shipping your own product. We will focus on secrets management and just inject them as you need them. Developers don’t have to do any context switching.
And then downstream, security teams also get what they want. They get visibility, they get control, they get audit trails, and they don’t have to fight the engineering team to get any of that.
Q. Can you tell us about the MCP server for Doppler? What does this tell us about where secrets management is heading and how teams should be thinking about secrets management and AI development?
This was an exciting launch for us. It’s also a reflection of where developer workflows are heading and we want to make sure we fit naturally into that world. For context, MCP is just a standard that lets tools like Claude, Cursor, or ChatGPT connect to other systems and interact with them conversationally. Our server gives those tools a secure, structured interface into Doppler’s secrets, configuration, and metadata. You scope that access to a token that you generate. Whatever permissions you have, you can go up to that. You can’t give it permissions you don’t have, and you can really tightly scope the permissions that token has.
In practice, instead of a developer having to stop what they’re doing, open our dashboard or go through docs or ask someone on the team, they can just conversationally chat to whatever AI tool they’re using. ‘Why is this deployment failing due to a missing config?’ The AI will call Doppler through the MCP, will authenticate, and return the answer. They don’t have to open a ticket or ask anybody or spend the time figuring that out.
I do want to be really clear about what it is not, because I think that’s important from a security perspective. There is no AI inside the Doppler product. Our customers have actually come to us in many different ways and said: please don’t put AI in your product.
They do not want it. A lot of security tools, they don’t want AI in them because it’s a risk and there’s a lot of concern around that. There’s a lot of unknowns. Right now, that is our stance. There is no AI inside Doppler. But our MCP server uses the exact same trust boundaries and authentication model as our API. If you’re using our API, it’s essentially the same permissioning. If you’re comfortable with that access, this doesn’t introduce a new risk class.
But if you’re not comfortable, if you don’t have policies around AI usage internally, if you don’t have an enterprise plan with an AI tool where you really understand how the data is being used, I wouldn’t recommend using this in production. We even say that in our docs. This is experimental, play around with it, use it in staging or tests, but use it at your own risk. It’s essentially the same kind of access as our API.
A lot of teams are trying to integrate AI into their workflows already and they’re cobbling it together. That creates security debt and operational debt. We’re just trying to provide a standardized, officially supported way to do this securely. Several people have built their own Doppler MCP server, the community has shared them out, but those weren’t vetted by us. We needed to build an official one so we knew it was safe to use and could give it assurances. That’s why we built this now and where we see the space heading.
Q. What practical advice would you give to security and engineering leaders who are looking to modernize their approach to secrets management?
The first step would be to understand what you can’t see. Understand your current exposure. Take the time to run a discovery exercise. Look at all your repos, your pipelines, your internal docs, your messaging tools. Talk to your team. Try to get an honest picture of where all the secrets live. As an organization, you’re going to discover a lot of things during that process that are going to surprise you. I wouldn’t consider that a failure if you discover something you don’t like. This is your baseline. This is where you start.
The second step is to put a tourniquet on it. Stop the bleeding. Establish some policies, even something simple like: secrets don’t live in code, period. Implement some sort of automated scanning that can catch secrets before they hit a repo. There are a lot of really great tools out there for that. That should be pretty table-stakes hygiene, no matter what.
Third, find a secrets management platform and consolidate. I would love for you to try Doppler, but we’re not the only one. That will give you visibility. It’s going to give you audit trails. It’s going to give you the ability to rotate things if something goes wrong. You’ll see how your team actually uses it in practice. If there is a breach, it’s a lot more manageable when you can revoke a single credential in one place, rather than trying to hunt down where it was and who touched it.
Fourth, and this is an area where a lot of organizations are under-investing: apply the same rigor to machine identities as you do to humans. Your service accounts, your tokens, your AI agents, they all need access controls. They all need rotation schedules or policies. They all need monitoring.
Finally, make the whole thing easy. Whatever you put in place, processes, tools, policies, think about the people that have to use them, which are going to be software developers. Treat your engineering team like a partner. Work with them. Don’t dictate to them what to do. Work with them to find out what will actually work for them. The organizations that get that right are going to be the ones where security and engineering are aligned together on the goal and finding tooling that supports both at the same time and actually gets used.
Listen to the full episode on Apple Podcasts
