Everyone on the team is using AI. Nobody is sure which credentials they're using, whose name the account is under, or what happens when someone leaves. This is the governance problem teams don't talk about until it becomes urgent.
It starts with one person creating an API key. Then a second person needs access, so they get the key too. Then a contractor needs it. Then someone pastes it into a shared .env file in the repo. Then that person leaves.
At no point did anyone say this was fine. It just happened, incrementally, because there was no structured alternative.
.env.local. Everyone has a copy.It was the path of least resistance. Now it's in six engineers' home directories, maybe a few editor config files, probably the CI logs from that one incident in March.
Nobody thought to revoke it. There's no list of who has which keys. The contractor probably still has access and either doesn't know it or doesn't care.
The honest answer is no. There's a billing dashboard that shows usage, but nothing that maps requests to identities, and no way to know which keys are still live.
The IT runbook covers email, GitHub, Slack, AWS. It has not been updated for the reality that engineers now have personal access to a dozen AI provider accounts.
Not "what do you think is probably true." Prove it. With a timestamp and a name.
Tenure sits between your engineers and the AI provider. Your org's real API key lives in one place. Every engineer authenticates through their own personal access token. Access is per-identity from the start.
Every engineer gets their own PAT. Their token is theirs. Their requests are attributed to them. Revoking one person's access doesn't require rotating a shared key or touching anyone else's setup.
PAT per userThe actual provider API key lives in one place: the Tenure deployment inside your cluster. Engineers never see it. It never lives in a .env file. It never leaves your infrastructure.
Tenure integrates with your identity provider via SCIM. When you deprovision an engineer in Okta, Azure AD, or Google Workspace, their Tenure access is revoked automatically. No manual step. No gap.
Automatic offboardingEvery request through the proxy is logged with identity, timestamp, and last_used_at per token. Stale tokens are visible. Active sessions are visible. Nothing is inferred from billing data.
The audit log isn't something you construct after an incident. It's written as requests happen. When someone asks who made a request at 4am, you open the log and show them.
The offboarding gap exists because AI credentials were granted outside the identity system. Tenure closes that gap by making your IdP the source of truth for access.
One step in Okta, Azure AD, or Google Workspace. The same step that revokes their email and GitHub access.
The identity provider calls Tenure's SCIM endpoint. No webhook configuration. No cron job. No manual step from your engineering team.
Every personal access token associated with the user is invalidated immediately. Existing sessions are terminated. The audit log records the event with the SCIM caller as the actor.
The audit log shows exactly when access was revoked, by which mechanism, and confirms zero successful requests after that timestamp. You can show this to anyone who asks.
last_used_at is stored on every PAT. Admins can see, at a glance, which tokens haven't been used in weeks or months. Stale tokens can be rotated or revoked on a schedule, not reactively after an incident.
| Token name | Owner | Last used | Scope |
|---|---|---|---|
| tok_mc_vscode_01 | marcus.chen | 2 hours ago | proxy:read |
| tok_pn_cursor_01 | priya.nair | today | proxy:read |
| tok_ak_ci_agent | alex.kim | 47 days ago | proxy:read |
| tok_jc_vscode_01 | j.contractor (ext) | never (revoked) | none |
| tok_tr_shared_dev | tom.r | 61 days ago | proxy:read |
Deploy Tenure inside your cluster. Connect your identity provider. Every engineer gets their own PAT, every request is attributed, and offboarding is one step in your IdP.
Helm chart · OIDC / SCIM · MIT licensed · No call-home telemetry