Secure API Key Management: Rotating and Revoking Credentials Across Open Source and Closed Source Integrations

TL;DR

• Rotation and revocation solve different problems: rotation is scheduled hygiene on your own timeline, revocation is an emergency response to a suspected or confirmed leak.
• Open source integration layers let you inspect exactly how a credential is stored, scoped, and encrypted, while closed source platforms ask you to trust a vendor's internal process and support team.
• Before touching any credential, map every place it is used: environment variables across environments, CI pipelines, background jobs, third party dashboards, and any AI agent or MCP server calling it.
• A planned rotation should overlap the old and new credential briefly so nothing breaks mid deployment. An emergency revocation should cut access immediately and accept some disruption as the cost of containment.
• Never assume a revoked credential is dead because a dashboard says so. Test it directly against the provider's API and watch your own logs for lingering authentication errors.
• Scoped, tenant isolated credentials, one key per connection instead of one shared key for an entire app, limit how much damage a single leaked credential can cause.

A single overlooked API key can undo months of careful engineering. It sits in a config file, a CI log, or an old Postman collection long after everyone assumed it was replaced, and the day it gets picked up by an automated scanner is rarely a day anyone chose. Secure api key management is not really about picking a strong string of characters. It is about knowing where every credential lives, how to replace it on your own schedule, and how to cut it off the moment something looks wrong.

This guide walks through that full lifecycle: the baseline practices that keep keys safe day to day, how developer tools and AI agents secure the calls they make, and the practical differences between rotating and revoking credentials on open source integration layers versus closed source, vendor hosted platforms. Whether you are managing a handful of static API keys or coordinating OAuth tokens across dozens of tenants, the same underlying discipline applies: know your dependencies, rotate on purpose, revoke without hesitation, and verify before you call it done.

Best Practices for Secure API Key Management

The core of secure api key management comes down to a short list of habits, applied consistently rather than occasionally: treat every key like a secret from the moment it is generated, not after the first time it leaks.

In practice, that means:

• Never commit credentials to version control: keep keys out of source files, config files checked into git, and CI logs that print environment variables during debugging.
• Store keys in a secrets manager or an encrypted vault: environment variables are an acceptable minimum for smaller projects, but a dedicated vault adds access logging and revocation without a redeploy.
• Scope every key to the narrowest permissions it needs: a restricted key that can only read orders is safer than a full account key reused everywhere, because a leak of the restricted key limits what an attacker can actually do.
• Issue a separate key per consumer where a provider allows it: one key per service, per environment, or per tenant means a single compromised key affects one connection instead of your entire integration surface.
• Set expiration dates wherever the provider supports them, and rotate on a fixed schedule instead of waiting for a reason: a key that expires on its own forces the habit even when nobody remembers to do it manually.
• Monitor key usage for anomalies: a sudden spike in calls, requests from an unfamiliar range of IPs, or activity outside normal hours is often the first sign a key has leaked, well before any formal alert fires.
• Write the rotation and revocation runbook before an incident happens: deciding who has authority to revoke a key, and where the replacement gets deployed, is a bad conversation to have for the first time during an active leak.

Multi tenant products add a layer on top of this list, since a single shared application key quietly becomes a single point of failure for every customer connected through it. Issuing a separate key per tenant, one of the practices above, deserves a closer look on its own, and Corsair's guide to API key management best practices for multi tenant apps walks through scoping keys per tenant and what changes once an AI agent starts calling those APIs on a user's behalf.

Securing API Calls in Developer Tools Through Authentication and Access Controls

Developer tools, from CLIs to SDKs to the coding agents now calling APIs on a developer's behalf, secure their calls through two layers working together: authentication, which proves who or what is making the call, and access control, which limits what that caller is allowed to do once it is proven.

Authentication itself usually takes one of a few shapes:

• Static API keys: a single long lived string sent with every request, simple to implement but risky if it never expires and grants broad access.
• OAuth 2.0: a flow that issues short lived access tokens plus a refresh token, adding user consent and defined scopes at the cost of more moving parts to implement correctly.
• Bot or service tokens: credentials scoped to a specific app or integration rather than an individual user, common in tools like Slack and GitHub.

Access control sits on top of authentication rather than replacing it. A caller can be fully authenticated and still be blocked from taking a destructive action, such as deleting a repository or sending a bulk email, if the platform gates that action behind an explicit permission or a human approval step. This matters more, not less, once AI agents are the ones making the calls: an agent holding a valid credential can still be stopped from executing an irreversible action if the integration layer checks permissions at the point of the tool call instead of only at login.

Encryption at rest is the part of this picture that is easy to skip and hard to retrofit. A credential should never sit in a database as plain text. Corsair encrypts every stored key using envelope encryption, where a root key encrypts a separate key for each connection, which in turn encrypts the credential itself, so compromising one connection's data does not expose every other tenant's keys. Combined with TLS on every request and signature verification on incoming webhooks, this layered approach is what actually stands between a leaked database backup and a full credential dump.

How Do Credential Rotation and Emergency Revocation Differ Across Open Source and Closed Source Integration Platforms?

Rotation and revocation solve two different problems, and the platform underneath you changes how much control you actually have over either one. Rotation is a scheduled replacement: you generate a new credential, migrate traffic to it, and retire the old one on your own timeline. Revocation is an emergency response: you cut off a credential's access immediately because it is suspected or confirmed to be compromised, and you accept some disruption as the cost of stopping active misuse.

Where a platform runs changes what each of those operations actually involves:

• Visibility: an open source integration layer that runs inside your own infrastructure lets you read the exact database row, encryption path, and code that handles a credential. A closed source, hosted platform gives you a dashboard state and, if something looks wrong, a support ticket.
• Speed: revoking a credential stored in your own database is typically instant, since deleting or invalidating a row takes effect the moment your application checks it. Revoking a credential that lives entirely on a vendor's infrastructure depends on that vendor's own propagation and caching layers, which you cannot inspect or speed up.
• Blast radius: self hosted, tenant isolated credentials limit a compromise to a single connection. A shared, vendor side integration key can span every customer routed through that vendor, so a single leak has a much wider reach.
• Auditability: open source code means you can read precisely what a rotate or revoke action does under the hood. Closed source means trusting the vendor's documentation, their support team, and their own internal incident history.

None of this makes closed source platforms unsafe by default. It means the guarantees you get are different: a closed source vendor promises to handle credential security correctly on your behalf, while an open source, self hosted layer gives you the ability to verify that it does. For a fuller comparison across licensing, extensibility, and long term cost, Corsair's breakdown of open source vs closed source integration tools covers the tradeoffs beyond credential handling alone.

Identifying Credential Dependencies and Affected Connections in API Integration Management

Before rotating or revoking anything, the first step in api integration management is finding every place that credential is actually used. Skipping this step is the single most common reason a routine rotation turns into an outage.

A useful inventory covers:

• Environment variables across every environment: development, staging, and production copies of a key are easy to update in one place and forget in another.
• CI and CD pipeline secrets: build and deploy jobs often hold their own copy of a credential, separate from what the running application uses.
• Background jobs and scheduled tasks: a cron job or queue worker that calls an API a few times a day is easy to miss because it rarely shows up in day to day traffic.
• Third party dashboards and BI tools: analytics platforms, data warehouses, and reporting tools frequently hold their own long lived copy of a key.
• AI agents and MCP servers: an agent that calls an API autonomously, on a schedule or in response to a trigger, is a consumer just like any service, and it needs to appear in the same inventory.

For multi tenant products, this step also means confirming whether a given credential is a single shared application level key or one of many per tenant credentials, since the blast radius and the communication required differ significantly between the two. Corsair's best practices for multi tenant OAuth covers how to structure that per tenant credential management before you ever need to rotate or revoke anything.

The most reliable way to keep this inventory accurate is to generate it from your integration platform's own connection records rather than maintaining a separate document that quietly goes stale. A live, queryable list of every active connection and which credential backs it turns dependency mapping into a lookup instead of a guessing exercise.

Executing Planned Credential Rotation and Emergency Revocation

Once the dependency map is in hand, executing the rotation or revocation itself follows two different playbooks, depending on whether you are working on a schedule or responding to an incident.

Planned rotation, step by step:

1. Generate a new credential alongside the existing one, using a provider that supports parallel validity where possible.
2. Update every consumer identified in the dependency inventory to use the new credential, working through environments in order rather than all at once.
3. Confirm traffic has actually shifted to the new credential by checking provider side usage logs or your own request logging.
4. Deactivate the old credential only after every consumer has been verified on the new one.

Emergency revocation, step by step:

1. Revoke the compromised credential immediately, even before a replacement exists. Stopping active misuse takes priority over avoiding downtime.
2. Check provider side logs for any unauthorized activity that occurred before revocation, since that history informs what else needs attention.
3. Generate a replacement credential and roll it out to every consumer identified in the dependency inventory.
4. Communicate the incident internally, including what was exposed, when, and what changed, so the same gap does not reopen later.

Where the tooling supports it, script both playbooks instead of clicking through a dashboard from memory under pressure. In Corsair, rotating a stored key is a single command per plugin and tenant:

pnpm corsair setup --plugin=linear api_key=lin_api_new_key --tenant=user_abc123

Or programmatically, for a rotation triggered by your own application logic:

await corsair

.withTenant("user_abc123")

.linear.keys.set_api_key("lin_api_new_key");

Because each tenant's key is encrypted independently, this single call replaces one connection's credential without touching any other tenant's data, which is exactly the isolation a rotation or revocation runbook depends on.

Verifying Old Credentials No Longer Work and Restoring Integration Services

A rotation or revocation is not finished the moment a dashboard shows the old credential as inactive. It is finished once you have confirmed, directly, that the old credential no longer works and every dependent connection is functioning on the new one.

Verification worth doing every time includes:

• Actively test the old credential: make a real request with it and confirm the provider returns an authentication error, rather than assuming a toggle in a dashboard took effect everywhere.
• Check for delayed propagation: some providers cache authentication decisions briefly, so an old key can keep working for a short window after it is revoked. Re test after a few minutes if the provider's documentation mentions any caching behavior.
• Watch application logs for authentication errors: a short burst of failed calls right after rotation is often expected during cutover, but failures that continue past that window point to a consumer that was missed in the dependency inventory.
• Restore and confirm each downstream service in turn: work back through the same list built during the dependency identification step, rather than stopping once the first or most visible integration is confirmed working.

Distinct, typed error signals make this step considerably easier than parsing generic failure messages. Corsair's error handling, for example, surfaces authentication problems as their own typed errors rather than a generic API failure, so an integration that has lost a valid credential is visibly different in your logs from one that hit a rate limit or a temporary outage. Once every dependency is confirmed on the new credential and the old one reliably fails, update the credential inventory to reflect the change and close out the runbook. That record becomes the reference the next rotation, planned or emergency, starts from.

Corsair is an open source integration layer built with this exact lifecycle in mind. Every plugin credential, whether a static API key or an OAuth token, is stored with envelope encryption in your own database and scoped per tenant by default, so rotating or revoking one connection never touches another. Typed authentication errors make verification straightforward instead of a guessing game, and because Corsair runs inside your own infrastructure under an Apache 2.0 license, rotation and revocation stay operations you control end to end. A free Hobby plan covers unlimited tool calls and up to 50 connections to get started, with a flat rate Pro plan at $200 a month once everything needs to be unlocked. Learn more at corsair.dev.

Frequently Asked Questions

How often should API keys be rotated?
There is no universal number, but a common working rule is every 90 days for keys with broad account level access, and longer intervals for narrowly scoped, low risk keys. Rotate immediately, regardless of schedule, the moment a key is suspected of exposure.

What is the difference between rotating and revoking an API key?
Rotation replaces a credential on a planned schedule while keeping service running, usually by overlapping the old and new key briefly. Revocation cuts off a credential's access immediately in response to a suspected or confirmed leak, even if that means temporary downtime while a replacement is issued.

Can API keys be rotated without any downtime?
Yes, if the provider supports issuing a new key while the old one stays valid for a short overlap window. Update every consumer to the new key during that window, confirm traffic has shifted, then deactivate the old key. Downtime during rotation is usually a sign a dependency was missed during the inventory step, not that rotation itself is inherently disruptive.

How does credential storage differ between open source and closed source integration tools?
Open source integration layers run inside your own infrastructure, so credentials are stored in your own database under keys you control, and you can read the exact code path that encrypts, stores, and injects them. Closed source platforms store credentials on the vendor's infrastructure, so rotation and revocation depend on that vendor's dashboard, API, and internal processes.

What should a team do immediately after a suspected API key leak?
Revoke the exposed key first, even before a replacement is ready, since stopping active misuse matters more than avoiding brief downtime. Then check the provider's usage logs for unauthorized calls made before revocation, identify everywhere the leaked key was used, and issue a replacement following the same dependency mapping used for planned rotations.