API keys often outlive the project that created them. The integration still works, so nobody wants to touch it; the developer who issued the key may have left; and the organisation may not know which systems depend on it. The credential has become an undocumented dependency.
Tie the key to an identity and purpose
A key should represent a known application, machine or service identity rather than an unexplained personal account. Define which resources it may access and which operations it may perform. An API application may need an associated machine identity to hold entitlements because the application itself is not always the object to which roles are assigned.
WebFrolic documents machine users associated with OAuth2 applications and supports granting global roles or explicit resource access to those machine identities. The design lesson is to separate the client requesting a token from the principal whose permissions determine what the token can do.
Make creation reviewable
At creation time, record the owner, purpose, target integration, intended network, permissions, rotation expectation and retirement process. Make risky scope visible. If the key can administer a tenant or change access for other identities, that should be a deliberate decision with a clear justification.
Avoid broad default permissions simply because the eventual use case is not yet known. Start with the narrowest workable grant and expand it only when an observed need and appropriate approval support the change.
Plan rotation around dependencies
Rotation is easier when the system owner knows which workload uses the key and how the replacement is deployed. Use overlap periods only when they are bounded and observable; otherwise the old credential can remain valid indefinitely. Verify that the old value stops working after cutover.
Deletion of a human account should prompt an inventory of related keys and integrations. WebFrolic’s documentation describes API-key revocation as part of account recovery; administrators should understand and communicate this consequence before a recovery operation affects production integrations.
Use telemetry to make ownership real
Record creation, use, scope changes, network changes, rotation and revocation where available. Logs should identify the acting identity without recording the secret itself. An unused key may be harmless, but it may also be an unowned credential waiting to be abused.
Review keys whose owner is missing, purpose is unclear or rotation date has passed. A register is a good start; automated enforcement is better where the platform supports it.
In practice
Assign each key to a named workload and accountable owner.
Scope permissions to required resources and operations.
Document deployment, rotation, revocation and recovery consequences.
Review keys with unclear purpose, owner or recent activity.