Quick answer: When you give an AI agent a raw API key, it can do everything that key allows — often your entire account. The fix is IAM: one scoped credential per agent, full audit logs, and revocation that doesn't require rotating keys for every other system.
What does it mean to give an agent an API key?
When you paste a Stripe secret key into a Cursor agent's context, or drop a GitHub PAT into an n8n workflow, you're granting that agent access to everything that key can do. For Stripe, that's customer data, payment methods, subscription controls, and webhook configuration. For GitHub, that's every repository the token has access to — reads, writes, and deletes.
AI agents are not employees. They don't have a sense of what's appropriate to access. They access whatever their tools allow them to access. If the tool (the API key) allows deleting production resources, the agent can delete production resources. That's not a flaw in the agent — it's a flaw in how the credential was issued.
What is the blast radius problem?
The blast radius is the scope of damage a compromised or misbehaving agent can cause. An agent with a full Stripe secret key has a blast radius that encompasses your entire billing system. An agent with a read-only, single-customer scoped credential has a blast radius of one customer record.
The blast radius problem is compounded when credentials are shared. If the same Stripe key powers your Cursor agent, your n8n billing workflow, and your Zapier sync — then revoking access means rotating the key, which breaks all three. So most teams don't revoke. They leave credentials running indefinitely, with no audit trail of which agent used which credential and when.
Why does this keep happening?
The tooling for human IAM (AWS IAM, Google Cloud IAM, Okta) was designed for humans — roles, groups, multi-factor auth. It wasn't designed for the pattern of dozens of AI agents making API calls on behalf of a developer or team. Most third-party services (Stripe, GitHub, Vercel) offer API keys but not per-agent scoping. So developers reach for what they have: a shared API key.
What is the principle of least privilege?
Least privilege is a security principle that says any actor — human or system — should have access to exactly what it needs to complete its task, and nothing more. For a human engineer, this means role-based access control with MFA. For an AI agent, this means scoped credentials: read-only when the task is read-only, write access only when write is required, and access revoked when the task is complete.
How do you apply least privilege to AI agents?
The pattern that works is a credential broker: a layer between your agents and your services that holds the raw credentials, issues scoped access per agent, logs every retrieval, and provides a single revocation point per agent.
- Store credentials once — in a vault, not in each agent's environment.
- Create a named identity for each agent — an access profile that defines which services it can reach.
- Issue scoped credentials at runtime — the agent requests a credential, the broker validates the policy and returns only what the agent is allowed.
- Log every access — which agent, which service, which timestamp.
- Revoke at the agent level — not the key level. Revoking one agent's access doesn't affect any other agent using the same underlying service.
What does a named agent identity look like in practice?
A named identity is just a configuration record — a name, a set of service permissions, and a token the agent uses to authenticate itself to the broker.
For a billing support agent, it might look like:
- Name: cursor-billing-support
- Stripe access: customers:read, subscriptions:read, billing_portal.sessions:create
- GitHub access: none
- Vercel access: none
- Token: a short-lived credential the agent includes in every
get_credentialrequest
When that agent calls get_credential for Stripe, the broker checks the policy, sees the request is permitted, and returns a scoped Stripe credential valid for that call. The agent never sees your actual Stripe secret key.
If you want to know what the billing support agent did last week, you query the audit log and filter by cursor-billing-support. Every access, every timestamp, every service.
What is IAM for AI agents?
IAM (Identity and Access Management) for AI agents is the application of these principles — least privilege, audit logging, instant revocation — to non-human agents. Instead of assigning credentials directly to agents, you give each agent a scoped identity with defined permissions. The credentials live in the vault. The agent's access profile defines what it can reach. Every access is logged.
What happens when you need to decommission an agent?
With shared keys, decommissioning is never clean. The key might be hardcoded in a config file, stored in an environment variable, or cached somewhere. You can't be sure it's gone until you rotate the key — and rotating means updating every other system that uses it.
With per-agent identities, decommissioning is a single operation: delete the access profile. The next credential request from that agent returns a permission denied. The underlying service credential is untouched. The agent is gone from your system in seconds, with a clear audit record of its last access.
IAM for agents at scale
At one or two agents, the overhead of per-agent identities feels unnecessary. At ten or twenty, the lack of it becomes the problem: you're managing a web of shared keys with no clear ownership, no audit trail, and no safe way to revoke access for any single agent without cascading effects.
The right time to set up agent IAM is before you have the problem, not after. Creating a named profile per agent from the start adds ten minutes per agent. Retrofitting it across twenty agents that all share credentials takes a week and introduces downtime risk.
What this looks like with Gazebo
You connect your services once. You create an access profile per agent. Each profile gets an MCP endpoint. Your agents call get_credential via MCP and get back only what their profile allows — logged, auditable, and revocable without rotating a single key.
For the full identity model, see IAM for AI agents. For a practical checklist of what to audit in your current setup, see the AI agent security checklist. For the full credential lifecycle — provisioning, scoping, auditing, and revocation — see API credential management.
What breaks first: a shared-key incident, step by step
It's a Tuesday. Someone on your team gets a Stripe alert: unexpected charges triggered on a handful of customer accounts. Not fraud — the API calls are authenticated. Something in your stack did this.
You have three systems using the same Stripe secret key: a Cursor billing agent, an n8n workflow that handles dunning, and a Zapier sync that mirrors subscription state to your CRM. All three have the key in their config. None of them log which Stripe calls they made or when.
Step one: you can't tell what happened.
Stripe's logs show authenticated API calls from your secret key. That's it. No agent name. No workflow ID. You're looking at a list of POST /v1/subscriptions calls and you have no way to know which of your three systems made them. You start manually cross-referencing Stripe timestamps against n8n execution logs, Cursor's history, and Zapier's task log. This takes hours. The logs don't line up cleanly — n8n shows a run in the right window, but so does Zapier.
Step two: you can't isolate the problem.
You want to suspend whichever system caused the issue while you investigate. But you have one key. Suspending access means rotating it, which immediately breaks n8n and Zapier. Your dunning workflow stops. Your CRM sync stops. You've now traded one incident for three.
You leave the key active because the alternative is worse.
Step three: you still can't confirm the fix.
After two days, you think you've found the bug — a prompt edge case in the Cursor billing agent that caused it to call subscriptions:update when it should have only read subscription state. You patch the prompt. But you have no way to verify the agent is now constrained to read-only behavior. The key still grants full write access. You're relying on the prompt not triggering the same path again.
This is the blast radius problem materializing. The credential was over-scoped. The systems were entangled. The audit trail was nonexistent.
The same incident with per-agent identities
Same billing agent. Same bug. Different outcome.
The Cursor billing agent has a named profile: cursor-billing-support. Its Stripe permissions are customers:read, subscriptions:read, billing_portal.sessions:create. Write access to subscriptions was never in the profile — the agent couldn't have triggered subscriptions:update even if the prompt told it to. The broker would have returned a permission denied.
But assume the permissions were misconfigured and write access was included. Here's what changes:
The audit log is immediate. You filter by cursor-billing-support in your credential broker's logs. Every Stripe call the agent made, timestamped, with the specific credential it used. You have your answer in under a minute.
Isolation is one operation. You delete the cursor-billing-support access profile. The agent's next credential request fails. n8n keeps running. Zapier keeps syncing. The underlying Stripe key is untouched. Your other systems don't notice.
The fix is verifiable. You update the access profile to remove subscriptions:write. Now it's structurally impossible for that agent to make that call — regardless of what prompt it receives. You're not trusting the prompt. You're enforcing the constraint at the credential layer.
The incident response goes from two days of log archaeology and a forced choice between isolation and downtime, to fifteen minutes of audit review and a single profile edit.
That's not a marginal improvement. It's a different category of system. One is manageable. The other is not — it just hasn't failed visibly yet.
The identity and access model described here is formalised as an open standard in the Agent Identity Protocol — covering how agents declare what they are, how users grant scoped consent, and how runtime enforcement is specified for conforming implementations.