API keys and service credentials remain one of the messiest parts of modern software development.
The problem is not simply that secrets need to be stored securely. We already have good tools for that. The larger unsolved problem is that credentials are created, copied, scoped, stored, injected, rotated, revoked, and audited differently across every API provider, cloud platform, hosting service, CI system, database, analytics tool, and developer environment.
This becomes painful during normal development. It becomes critical after a compromise.
When a local npm package steals environment variables, a .env file leaks, a GitHub repo is exposed, a CI log reveals secrets, or a developer laptop is compromised, the standard advice is: “Rotate your keys.”
But in practice, that means answering hard questions quickly:
- Which credentials were exposed?
- What can each credential access?
- Where is each credential used?
- Which projects, jobs, deploys, scripts, and dashboards depend on it?
- What is the safe order of rotation?
- Can we update the replacement everywhere before revoking the old key?
- How do we know production will not break?
- How do we prove the recovery was completed?
Today, there is no common, vendor-neutral way to answer those questions.
This proposal is not for another secrets manager, password vault, IAM system, OAuth flow, or secret scanner. Those tools already exist and many are excellent.
The missing piece is a shared credential lifecycle standard.
Existing tools solve pieces of the problem:
- Secrets managers store and sync credentials.
- Cloud IAM systems issue credentials inside specific cloud ecosystems.
- OIDC federation can reduce the need for long-lived secrets in supported CI/cloud workflows.
- OAuth and OIDC help with delegated authorization and identity.
- Secret scanners detect exposed credentials.
- Custom scripts can automate one vendor or one team’s workflow.
But none of these provide a general, cross-vendor convention for discovering how credentials are created, scoped, approved, injected, inventoried, rotated, revoked, and audited across the broader software ecosystem.
The proposed new layer is a standard way for providers to expose credential lifecycle capabilities to approved tools and agents.
A simple starting point could be a machine-readable endpoint such as:
/.well-known/credential-issuerThis endpoint would tell developer tools how a provider handles credential creation, permission scopes, rotation, revocation, audit trails, and supported authentication methods.
The goal is to make credential lifecycle management discoverable, automatable, auditable, and interoperable.
After a hack or suspected leak, developers need a fast way to map the credential blast radius.
A compliant tool should be able to say:
These credentials may have been exposed. Here is what each one can access. Here is where each one is used. Here is what will break if you revoke it. Here is the safest rotation plan.
This turns incident response from a manual scavenger hunt into a structured recovery workflow.
Developers should be able to rotate all credentials for a project without visiting a dozen vendor dashboards.
A tool should be able to:
- Create replacement credentials.
- Apply equivalent or tighter scopes.
- Update approved secret stores and deployment targets.
- Redeploy or refresh dependent systems.
- Run health checks.
- Revoke the old credentials.
- Save a complete audit trail.
Credential rotation should be a safe workflow, not a high-risk copy-paste ritual.
A team should be able to answer:
Where is this key used?
The answer should include local development, GitHub Actions, Vercel, Netlify, Cloudflare, Docker, Kubernetes, serverless functions, cron jobs, databases, analytics scripts, notebooks, and any other approved target.
Without a usage graph, rotation and revocation are dangerous because no one knows what will break.
Revoking a credential should not require guesswork.
A lifecycle-aware tool should know whether a replacement credential has already been installed everywhere it needs to be, whether health checks have passed, and whether it is safe to revoke the old credential.
Many credentials are broader than they need to be because the secure path is too tedious.
A lifecycle standard would allow tools to identify overbroad credentials and replace them with narrower ones:
This app only reads analytics events, but the current key has full admin access. Replace it with a read-only project-scoped credential?
As AI agents become more involved in software development, they will need a safe way to request access.
The wrong pattern is:
Paste your API key here.
The better pattern is:
This agent requests read-only access to PostHog events for Project X for 30 minutes. Approve?
The request should be scoped, logged, expiring, revocable, and approved by the user or organization.
The standard would define a provider-facing credential lifecycle manifest.
Example:
{
"issuer": "ExampleAPI",
"credential_issuer_endpoint": "https://api.example.com/credentials",
"supported_credential_types": [
"api_key",
"oauth_client",
"webhook_secret",
"service_account"
],
"supported_operations": [
"discover",
"request",
"approve",
"create",
"scope",
"rotate",
"revoke",
"audit"
],
"auth_methods": [
"passkey",
"oauth",
"oidc",
"sso",
"hardware_key"
],
"permission_schema_url": "https://api.example.com/.well-known/credential-permissions",
"supports_expiring_credentials": true,
"supports_workload_bound_credentials": true,
"supports_rotation": true,
"supports_revocation": true,
"supports_audit": true
}A developer tool, secret manager, CI platform, cloud service, or coding agent could read this manifest and understand how to interact with the provider’s credential system in a standard way.
The standard should eventually support:
-
Discover Find the provider’s credential lifecycle capabilities.
-
Request Ask for a credential for a specific project, workload, user, agent, environment, or task.
-
Approve Require human or organizational approval using passkeys, SSO, hardware keys, OAuth, OIDC, or other trusted methods.
-
Create Mint a credential with the narrowest appropriate permissions.
-
Scope Define what the credential can access, which environment it belongs to, and what actions it can perform.
-
Store Store the credential in an approved secret store, vault, local secure enclave, cloud secret manager, or team credential broker.
-
Inject Place the credential into approved targets such as local dev, CI, hosting platforms, serverless functions, jobs, and deployment environments.
-
Inventory Record where the credential is used and what depends on it.
-
Rotate Create a replacement, update all known dependents, run checks, and revoke the old credential only when safe.
-
Revoke Disable a credential immediately or after dependent systems have been migrated.
-
Audit Record who or what requested, approved, created, accessed, rotated, or revoked the credential.
This proposal is meant to complement existing tools, not replace them.
A secrets manager could use the standard to understand how to rotate credentials at the source.
A CI platform could use it to request short-lived credentials for a specific build.
A cloud provider could expose its IAM and workload identity capabilities in a more discoverable way.
An API provider could let developers create and rotate restricted keys without clicking through a custom dashboard.
A secret scanner could trigger a recovery workflow rather than merely warning that a key was exposed.
An AI coding agent could request temporary, least-privilege access without ever seeing or storing a broad permanent key.
The standard is the connective tissue between these systems.
A developer installs a malicious package that steals local environment variables. The team needs to identify every credential that may have been exposed, determine what each one can access, rotate them, update all dependent systems, and revoke the old credentials.
Today this requires manual effort across many dashboards. With a lifecycle standard, a recovery tool could generate and execute a safe rotation plan.
A private repository containing .env values is accidentally made public. A lifecycle-aware system could identify the exposed credentials, check where they are used, create replacements, update GitHub Actions and hosting environments, run tests, and revoke the old keys.
A contractor had local development access to a project. The team wants to revoke their access and rotate any shared credentials they may have seen. A credential usage graph would show which credentials need to be replaced and where they are used.
During a handoff, audit, or acquisition, the receiving team needs to know which credentials exist, who owns them, what they can access, when they were last rotated, and how to replace them. A credential lifecycle manifest and usage graph would make this inspectable.
A production app uses a full admin API key when it only needs read access to a subset of data. A lifecycle-aware tool could recommend a narrower credential, create it, deploy it, verify the app still works, and revoke the overbroad credential.
A coding agent needs to inspect analytics data or update a deployment setting. Instead of giving it a permanent API key, the agent requests narrowly scoped temporary access. The user approves the request, the credential is issued, the action is logged, and the credential expires or is revoked when the task is complete.
Credentials should not be random strings copied by humans into unknown places.
They should be lifecycle-managed objects with identity, purpose, scope, ownership, storage location, usage graph, expiration, rotation history, and revocation path.
API providers, secret managers, cloud platforms, CI/CD systems, hosting platforms, package registries, developer tools, and standards communities should collaborate on a shared credential lifecycle convention.
The first version does not need to solve everything. It could start with:
- A
/.well-known/credential-issuermanifest - A standard permission schema format
- Standard create, rotate, revoke, list, and audit operations
- Support for strong human approval and workload identity
- Metadata describing intended use, owner, project, environment, expiration, and rotation policy
The immediate goal is simple:
Make it possible for developers to recover from credential compromise and rotate project credentials safely, quickly, and consistently across providers.
The long-term goal is broader:
Replace scattered, human-copied API keys with discoverable, least-privilege, auditable, lifecycle-managed credentials across the software ecosystem.