When one of your API keys leaks, the real question isn’t “how did it happen?” It’s “how much damage can it do before you notice?”
We built a tool to answer that question systematically. What we found in the data surprised even us.
The Question Nobody Was Asking
After a breach, most teams rotate the compromised key and move on. Add a scanner to the CI pipeline, add it to the post-mortem, ship a new secret. But almost nobody asks the question that would have mattered before the incident: what could that key actually reach?
The security tooling industry has invested heavily in detection. GitGuardian and TruffleHog are good at finding credentials that have already leaked. Detection tells you a key is out there. It doesn’t tell you what an attacker can do with it once they have it.
That gap matters more than most teams realize. A Stripe API key with full write access can initiate payouts, modify customer records, and cancel subscriptions. A read-only analytics key from the same service can pull aggregate revenue data. Both get flagged identically by a scanner. The threat they represent is completely different.
The question almost no team can answer before an incident is: what is this key’s blast radius? How much can it do, how many systems does it touch, and how long would we take to notice someone else using it?
Modeling exposure scope before something goes wrong is where most teams have nothing. That’s what we decided to build.
What Is a Credential Blast Radius?
Blast radius is a term we borrowed from distributed systems to describe the total scope of damage a single leaked credential can cause.
It’s not the same as severity. Severity is a property of the credential itself: does it have write access, does it touch production, is the service it controls important? Those things matter. Severity alone misses half the picture.
A low-privilege key used by 47 different services has enormous blast radius. If it leaks, an attacker can map your entire infrastructure just by watching which calls succeed. Read-only access at that scale is genuinely dangerous.
Blast radius has four components:
- Permissions scope: what the key can actually do (read, write, admin, billing access)
- Service criticality: how important the target service is to your operations
- Blast width: how many downstream agents, pipelines, or systems hold that key
- Detection lag: how long before you’d notice the key being used by someone else
The combination of these four factors determines actual risk. A key that scores low on the first three but has a detection lag measured in weeks is still a serious problem. The attacker just has more time to operate quietly without triggering anything.
How We Built the Report
We started by mapping permission scopes across the API providers most teams use in production: AWS, OpenAI, Stripe, GitHub, Twilio, Slack, and several others. For each provider, we documented the gap between their most permissive and most restrictive credential options.
Then we modeled real agent identity patterns. Specifically, we looked at two common approaches: one API key shared across multiple agents versus scoped keys issued per agent. Both patterns are common in production. Their blast radius profiles are completely different.
For each credential pattern, we scored it on the four axes above. The scoring isn’t a definitive risk number. It’s meant to make comparison concrete. “High write access, medium service criticality, blast width of 8, detection lag of 3 days” is a more actionable description than “high risk.”
We also looked at how agent runtimes and MCP sessions change the detection picture. Traditional secrets management wasn’t built with autonomous agents in mind. That creates visibility gaps that affect detection lag specifically.
Four findings came out of the analysis consistently, across most of the patterns we evaluated.
Finding #1: Most Teams Give Agents Root-Level Keys
The majority of AI agent integrations we analyzed use admin or full-scope API keys. Not by design. Because scoped keys are harder to set up.
OpenAI’s API supports project-scoped keys with specific permission sets. Anthropic has workspace and project-level credential separation. AWS has IAM roles with fine-grained policies. The tooling for least-privilege access exists across all major providers. The default patterns don’t use it.
When a developer connects an agent to OpenAI, the path of least resistance is an API key generated at the account level. That key can list and delete fine-tuning jobs, view billing, read all usage data, and make inference calls without constraint. Most developers don’t realize that’s what they’re handing the agent. They just need it to work.
The blast radius of a leaked account-level OpenAI key is significant. An attacker with that key can access your entire Assistants API conversation history, inspect any fine-tuned models you’ve built, review billing and usage data, and make arbitrary calls on your behalf.
The fix exists. Creating a project-scoped key with only the inference permissions your agent needs takes two minutes in the OpenAI dashboard. The reason it rarely happens is that most documentation doesn’t mention it, and most teams only think about scope after something goes wrong.
Finding #2: Shared Keys Multiply Blast Radius Exponentially
A single API key used by 12 different agents means 12 separate attack surfaces for one credential.
This is the most common pattern we see in multi-agent architectures. One OpenAI key shared across every agent in the system. One GitHub token used by the deployment agent, the code review agent, and the documentation generator. One Stripe key sitting in every service that touches billing.
The blast width compounds risk in two distinct ways.
First, any agent that holds the key is a potential leak path. Prompt injection in agent A can extract the key and send it externally. A supply chain compromise in a dependency used by agent B can exfiltrate it. The attacker only needs to compromise one agent to get a key that unlocks all twelve.
Second, when the key leaks, the attacker isn’t limited to what agent A was designed to do. They have the full permission set of the key, across every use case it was originally created for. If the shared OpenAI key has write access to fine-tuning, every agent that holds it effectively grants that capability to anyone who gets the key.
Rotating a shared key to contain a breach means interrupting every agent that uses it simultaneously. Teams often delay rotation because of this operational cost. That delay extends the detection window and makes the blast radius worse, not better.
One key per agent, scoped to only what that agent needs, is the answer. It’s more credentials to manage. It’s also dramatically smaller blast radius for each individual one.
Finding #3: Time-to-Detection Is the Real Multiplier
The other three factors determine the potential blast radius. Detection lag determines how much of that potential actually gets realized.
We looked at detection timelines for leaked API keys in production environments. The numbers aren’t good. Average time to detect a leaked key being actively used: days, not hours. Some cases stretch to weeks before anyone notices anomalous activity.
Every hour of undetected use extends the blast radius. An attacker with 72 hours of undetected access to a write-capable key can do a lot: data exfiltration, configuration changes, dependency mapping, quiet backdoor provisioning. The permissions scope sets the ceiling. Detection lag determines how much of that ceiling gets used.
Agent runtimes make this worse. Traditional API monitoring watches for unusual call volumes or unexpected source IPs. Agents make high-volume API calls by design. An attacker using a leaked agent credential blends into normal agent behavior. The signal-to-noise ratio is bad and getting worse as agents handle more of the work.
MCP sessions create another blind spot. When an agent operates through an MCP connection, session logs often capture that a call was made without recording what the agent actually did within that call. You can see that the credential was used. You can’t always reconstruct what it was used for or what data it touched.
Detection lag is the factor teams have the most ability to improve quickly. Audit logs tied to agent identity, anomaly baselines built from known-good agent behavior, and rotation cadences that limit the window of exposure all reduce it directly. Most teams haven’t built any of that. The credential sits in a secrets manager with a long TTL and no behavioral baseline attached.
Finding #4: Agent Identities Are the New Attack Surface
Traditional role-based access control was built for human users. A human in a role does a predictable set of things. Access controls are designed around that predictability.
Agents are different. An agent can be prompted to act outside its intended scope. Prompt injection is the obvious vector, but not the only one. A customer support agent with write access to a CRM can be induced to export customer data if the right input reaches it. A code review agent with repository write access can be manipulated into committing changes. The credential defines what’s possible. The prompt influences what actually happens.
This is what makes agent identities a new attack surface. It’s not that credentials are weaker. It’s that the entity holding the credential is more malleable than a human operator. You can’t social-engineer a human into performing actions they don’t intend to perform without their awareness. With the right input, you can prompt an agent into doing exactly that.
The blast radius consequence is serious. An agent with broad credentials isn’t just a potential leak source. It’s a potential insider threat vector. The credential doesn’t need to leave the system. The attacker just needs the agent to use it in unintended ways.
Tighter prompts help at the margin. They’re not a solution. The real fix is scoped, session-bound credentials that expire when the task ends. An agent that can only do what its current task requires, using a credential valid only for the duration of that task, has limited blast radius regardless of what lands in its context window.
How to Run a Blast Radius Audit on Your Own Stack
You can run a basic version of this analysis on your own infrastructure without special tooling. It takes a few hours and produces a list of priority targets.
Step 1: Inventory every credential in use by agents and pipelines. Don’t stop at your secrets manager. Check .env files in your repositories. Check CI/CD environment variables in your pipeline configuration. Check hardcoded configs in infrastructure-as-code templates and agent initialization scripts. Most teams find 20-30% more credentials than they knew about during this step.
Step 2: Score each key on the four axes. For each credential, assign a rough score from 1 to 3 on write access (1 = read-only, 3 = admin or billing), service criticality (1 = non-critical, 3 = core production), blast width (1 = used by one system, 3 = shared across many), and detection lag (1 = actively monitored with baselines, 3 = no alerts, no rotation schedule). Precision isn’t the goal. You need enough signal to sort.
Step 3: Flag anything scoring high on two or more axes. A key with high write access and high blast width is a priority target for scoping and rotation. A key with high service criticality and high detection lag needs monitoring improvements first. Any key scoring high on three or four axes needs immediate attention.
Step 4: For each flagged key, define the minimum permission scope and a rotation cadence. Answer two questions: what is the smallest permission set that would still let dependent systems function, and how often should this key rotate? These don’t need to be perfect answers. They need to be better than the current default, which for most teams is admin scope and no rotation schedule.
Run this audit once, then build it into onboarding for any new agent integration. The goal is making the blast radius of any single leak smaller than it is today.
What Shrinks Blast Radius
Everything in the audit above points toward the same practices.
Least privilege applied per agent, not per team. Giving a team a shared key with broad access and trusting them to use it carefully doesn’t reduce the blast radius. It distributes it across more agents. Each agent that touches infrastructure should have its own credential scoped to exactly what that agent’s tasks require.
Session-scoped credentials that auto-expire. The phantom token pattern: the agent receives a short-lived credential at the start of a task, and it becomes invalid when the task ends. Even if the credential leaks mid-task, the window of exploitation is minutes. Not weeks.
Centralized credential brokering so agents never hold raw keys. When agents request tokens from a broker rather than storing credentials directly, the blast radius of a compromised agent is contained. The broker validates the request, issues a scoped token, and logs the transaction. The agent never sees the underlying secret.
Audit logs tied to agent identity, not just key identity. “This key was called 3,000 times today” is much less useful than “agent-fraud-detection made 3,000 calls to Stripe using key X during session Y.” The second form lets you detect anomalies and reconstruct what a compromised agent actually did.
None of these practices are new. They’ve been standard for human identity management for years. The gap is that most teams haven’t applied them to agent identities yet.
That audit process is manual. At small scale, it’s manageable. At 20 agents, 50 credentials, and multiple environments, it stops being something you finish in an afternoon.
API Stronghold runs this analysis automatically for every credential in your vault. You get a blast radius score for each agent showing which keys carry the most risk, which agents share credentials they shouldn’t, and where your detection lag is highest. Try it free: https://app.apistronghold.com/signup