Quick answer: Rotation replaces a secret — you generate a new key and update every system that uses the old one. Revocation cuts one identity's access instantly without touching the underlying key at all. For AI agents, revocation is almost always the right response. Rotation is what you fall back on when you didn't have revocation set up first.
What is key rotation?
Rotation means generating a new API key and replacing the old one across every system that depends on it. If your Stripe key is compromised, you go to the Stripe dashboard, generate a new key, update it in your server's environment, your CI pipeline, your staging environment, your Vercel project settings, and anywhere else it lives — then hope you didn't miss one.
Rotation is disruptive by design. It invalidates the old key everywhere simultaneously. That's the point: a compromised key stops working. But it also means everything using the legitimate copy of that key breaks until updated. At small scale, this is annoying. At agent scale — where dozens of tools, workflows, and automations share a credential — it becomes the reason teams avoid revoking access at all.
Why rotation is the wrong default for agents
The shared-key problem is the root of it. Most teams give their Cursor agent, their n8n workflow, and their Zapier integration the same Stripe key. It's the path of least resistance: one key to manage. But it means you now can't revoke one of them without breaking all of them.
So when the Cursor agent does something unexpected — writes to production, reads data it shouldn't have, runs up an API bill — the technically correct response is to revoke its access. The practical response, since you can't revoke just one user of a shared key without rotating it for everyone, is to do nothing. Leave the key running. Maybe review the agent's behavior later. Probably don't.
That's not a security policy. That's just friction winning.
The other problem: rotation assumes you know everywhere a key is used. In practice, you don't. A key that's been around for a year has often ended up in more places than anyone can enumerate — old deployment scripts, teammate's local environments, a workflow someone built six months ago. Rotating it means breaking things you didn't know were there.
Revocation as the agent-native response
Revocation works differently. Instead of rotating the underlying key, you revoke a specific identity's access to it.
The pattern: you don't give agents your actual API keys. You give each agent a scoped access profile — a named identity that says "this agent can reach these services, with these permissions." The real key lives in a vault. The agent holds a profile token. When the agent calls get_credential, the broker checks the profile policy, logs the access, and returns the credential — or denies the request.
To revoke the agent: delete the profile. The next get_credential call returns a permission denied response. The underlying Stripe key, GitHub token, or Vercel credential is untouched. Every other agent keeps working. Nothing breaks for your other systems.
Revocation is cheap enough to use routinely — not just in a crisis. Because it doesn't require coordinating updates across every system that uses a shared key, you can actually do it when you should, not just when you have no choice.
Worked example: an agent goes rogue
Your Cursor agent has access to your Stripe account for billing-related tasks. You notice unexpected API calls in your Stripe logs — the agent has been hitting customer endpoints it wasn't supposed to need.
With rotation: You generate a new Stripe key. You update it in six places. Your Vercel production environment breaks until you find the right config. Your n8n billing workflow starts failing. An hour later you've updated everything. Meanwhile the suspicious activity has been running for the duration.
With revocation: You delete the Cursor agent's access profile in Gazebo. Its next call gets a permission denied response. Your Stripe key is unchanged. Your n8n workflow, your Vercel environment, your other agents — none of them notice. You have a full audit log of exactly what the agent accessed and when, so you know the scope of what happened.
The difference isn't just speed. It's that revocation doesn't require you to understand the full blast radius of a shared key before you can act. You can revoke first and investigate after.
When rotation is still the right call
Revocation handles the agent problem, but rotation still has its place:
When a key is confirmed compromised externally. If a key was accidentally committed to a public repo, included in an error message, or discovered in a breach, rotation invalidates the exposed credential across the board — you're not just removing one agent's access, you're ensuring no one holding the old key can use it.
For infrastructure keys that services rotate on a schedule. Database passwords, TLS certificates, and IAM session credentials often have enforced rotation schedules. Vault's dynamic secrets and AWS IAM's credential rotation handle this at the infrastructure level — this is complementary to, not competing with, per-agent revocation for external APIs.
When you're migrating off a shared key. If you're retrofitting per-agent identities onto a system that previously used a shared key, there's a transition period where both exist. Once all agents have been migrated to their individual profiles, you rotate the old shared key as a clean cutover — then everything's on the new model.
The rule of thumb: revocation for agent access control, rotation for key compromise or scheduled credential hygiene.
Automating rotation for infrastructure keys
For infrastructure credentials (database passwords, TLS certificates, AWS session tokens), automated rotation is the right approach:
- HashiCorp Vault dynamic secrets — Vault generates a short-lived credential per request (minutes to hours) rather than a long-lived key. The credential expires automatically; there's nothing to rotate manually.
- AWS IAM role assumption — roles issue temporary session credentials with a defined expiry. Applications assume the role, not the underlying key.
- Periodic rotation scripts — for services without dynamic secret support, scheduled rotation jobs (weekly, monthly) with automatic config updates reduce manual burden.
The goal is the same as revocation: reduce the blast radius of a compromised credential by limiting its lifespan and scope.
Emergency response: which to use when
| Situation | Right response |
|---|---|
| A specific agent is misbehaving or compromised | Revoke that agent's profile |
| A key was accidentally committed to a public repo | Rotate the key immediately |
| You're decommissioning an agent you no longer need | Revoke the profile |
| A vendor notifies you of a breach | Rotate all credentials for that service |
| An agent needs its access narrowed, not removed | Update the access profile (no rotation needed) |
| You suspect a key has been shared through agent prompts | Rotate; then set up brokered access going forward |
The practical setup
Revocation only works if agents don't share credentials in the first place. If your Cursor agent and your n8n workflow both hold the same Stripe key directly, you can't revoke one without the other — you're back to rotation.
The prerequisite is one scoped identity per agent, each with its own credential surface, connected to a vault that holds the real keys. That's the access profile model Gazebo is built around — each agent gets a named profile, the vault holds the underlying credentials encrypted with AES-256-GCM, and revocation is a single delete operation. See the security overview for how the vault is structured.
Building the habit: revocation as routine, not emergency
One underappreciated benefit of per-agent revocation is that it normalizes deprovisioning. With shared keys, revocation is an emergency procedure — you only do it when something goes visibly wrong, because the operational cost of coordinating a key rotation is high. So most incidents go unaddressed.
With per-agent profiles, revocation is a routine operation. When a task is complete, revoke the profile. When an agent is deprecated, revoke it. When a test workflow is done, revoke the test profile. The cost is one operation with no downstream effects.
This changes the security posture in a meaningful way. Teams that revoke routinely tend to keep their active profile list short and clean. Teams that only revoke in emergencies accumulate stale profiles — active credentials for agents that haven't run in months, connected to services the team may have forgotten about.
A useful health check: pull a list of active agent profiles and when each one last made a credential request. Profiles that haven't been used in 30 days are candidates for deprovisioning. The goal is a state where every active profile represents an agent that's actually running right now and needs that access. That's the security posture per-agent revocation enables — not just faster incident response, but a smaller attack surface to defend in the first place.
For a practical guide to building the per-agent identity model that makes revocation work, see IAM for AI agents and AI agent permissions.