Revoke and undo
Shut a leaked key at the provider, with ten minutes for you to cancel.
These pages describe ShellOrbit as it runs today. Breaking changes to the HTTP API are announced before they ship, and existing request and response shapes stay supported.
What can be revoked
| Provider | What ShellOrbit does | How it finds the right one |
|---|---|---|
| AWS | Deactivates the leaked access key | Lists your users’ access keys and matches the exact key to the finding’s fingerprint |
| OpenAI | Deletes the leaked project key | Lists your projects’ keys and matches the redacted value; acts only when exactly one key matches |
| Supabase | Turns on Row Level Security for a table anyone can read | Uses the project and table named in the finding, only in the project you connected |
| GitHub | Reports the token to GitHub, which revokes it and tells its owner | The token itself, at the moment a scan finds it |
Revoking is on Pro and Business. On every plan, Leak Alarm still finds the leak and gives you the fix.
ShellOrbit never uses a leaked key to check whether it works, and never sends one to a provider as a credential.
Connect an account
In the dashboard, open Settings, then Connected accounts. Each provider is connected separately, and each credential is encrypted, never shown again, and deleted when you disconnect.
AWS. Create a role named ShellOrbitLeakAlarmRevoke that trusts ShellOrbit’s AWS account with the external id shown on the page, then attach this permission policy and nothing else:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FindTheLeakedKey",
"Effect": "Allow",
"Action": ["iam:ListUsers", "iam:ListAccessKeys"],
"Resource": "*"
},
{
"Sid": "DeactivateTheLeakedKey",
"Effect": "Allow",
"Action": "iam:UpdateAccessKey",
"Resource": "arn:aws:iam::*:user/*"
}
]
}The role cannot read a secret, create a key, or change anything else. ShellOrbit can assume only a role with exactly this name, and only with your external id. Paste the role ARN into the page and ShellOrbit checks it before saving.
OpenAI. Create an admin key in your OpenAI organization settings, under Admin keys, and paste it in. ShellOrbit uses it to list projects and their keys and to delete the one leaked project key, nothing else. Keys owned by users or service accounts are reported but cannot be deleted this way.
Supabase. Paste a Supabase access token and the project ref of the project to protect. Supabase access tokens currently reach every project your account can reach, so ShellOrbit only ever sends the one statement that turns on Row Level Security, and only for tables in the connected project.
GitHub. Turn on reporting. Nothing is stored: GitHub’s revocation service needs no credential.
Choose per key
Each connected account is alert only until you change it. You can:
- press Revoke (or Lock table for Supabase) on a finding, or
- tick Revoke new keys automatically on the account, so every new key it can act on is scheduled for you.
Cancel revoke stops it and marks that key alert only, so nothing acts on it again until you press Revoke yourself.
What happens
- The revoke is scheduled ten minutes out. You are alerted by email, Slack, or Discord, and the finding shows the countdown.
- Cancel from the dashboard at any time in those ten minutes.
- Otherwise ShellOrbit acts on the exact key or table at the provider, then asks the provider to confirm it worked.
- You are alerted with the result, and the finding shows when it was revoked. A revoked key still in your code stays a finding until you remove it, and is never revoked twice.
If the provider refuses, or more than one OpenAI key could be the leaked one, nothing is changed: the finding shows why and you are alerted. Every scheduled, cancelled, completed, and failed revoke is in the audit log.
GitHub tokens are the one exception to the ten minutes. ShellOrbit never keeps a token, so it can only report one at the moment a scan finds it, and GitHub cannot reactivate a revoked token.
Before you allow it
Revoking a key your app still uses takes that part of your app down, and locking a table can stop your app reading it until you add policies. Rotate first where you can: create the new key, deploy it, then let ShellOrbit revoke the old one. The ten minutes exist so a mistaken match never costs you an outage.