Per-employee AI governance means every person's AI access is a single, named key — issued on hire, budgeted by their role, attributed to them by default, and tied to the same directory that already governs their laptop, badge, and every SaaS seat they own.
If you run People-ops, you don't have that today. You have the opposite: everyone has AI tools, and nobody owns the list.
You can't answer basic questions. Who has Copilot? Who expensed Claude Pro on a personal card? How many of the 200 seats you bought are actually used? And the one that keeps you up: what happened to all of that access when someone left last month?
Why "everyone has AI" is your problem now
AI access grew the way shadow AI always grows — bottom-up, one work email and one personal card at a time. That leaves People-ops holding four problems no other seat type has:
Seat sprawl. The same tool bought three times across three teams, because nobody reconciled them. You're paying for duplicates you can't even see.
Shadow AI. People signed up for models you never approved, never inventoried, and can't put on a budget. It's spend leaving the building with no owner. (We wrote the full version of this in Shadow AI Is a Budget Problem.)
No per-person budget. Every other seat has a cost and an owner. AI is a pile of invoices with neither. An engineer, a support rep, and an exec all draw from the same undifferentiated pool.
Orphaned access. Someone leaves, and their AI access doesn't. It's not on the offboarding checklist because it was never on the onboarding one. The key keeps working, and the spend keeps running.
You already solved this shape of problem years ago — for badges, laptops, and SaaS. AI is the one kind of access you left ungoverned. Per-employee AI governance is just applying the playbook you already run.
The model: an AI key per employee, tied to your HRIS
The unit of governance is a Virtual AI Key — a tk_live_ key issued to one person, not one team or one app. Because the key belongs to a human, everything you'd want to govern hangs off it:
- Provisioned by role. Each key carries a budget set on the way in. An engineer's budget isn't a support rep's isn't an exec's. The cap is decided at issue, before the spend — not discovered on an invoice after.
- Attributed by default. Every call answers five dimensions — WHO / HOW MUCH / WHY / WHERE / WHEN — so you never have to ask "whose $4,000 is this?" again. (See AI Cost Attribution for how the five dimensions work.)
- Hard-capped at the gateway. The budget is enforced on the key by the gateway itself: hit the cap and the call is refused with an HTTP 402 before it reaches the model. Budgets aren't a spreadsheet you reconcile later; they're a wall the key can't walk through. (What's a token, and why is it the unit of spend?)
- Bound to a second factor. A binding key ties each Virtual AI Key to where it's allowed to run, so a leaked key is a dead key.
- Fed by your HRIS. Tokenality ingests your directory — BambooHR, Workday, and Rippling connectors are live today — so every key maps to a real person, team, and manager on your org chart. Seat and usage reporting then shows you exactly what's used, what's idle, and what's waste.
That last point is where the leaver question gets an honest answer.
The joiner-mover-leaver lifecycle
Here's each HR event and exactly what happens to the employee's AI key — including what's shipped and what's on the roadmap:
| HR event | What happens to the AI key | Status |
|---|---|---|
| Joiner — someone is hired | HRIS feed brings them in; a Virtual AI Key is issued, budgeted for their role | Directory ingest live (BambooHR / Workday / Rippling) |
| Mover — role or team change | The feed reflects the new role; budget and attribution follow the person, not a stale group | Ingest live |
| Seat sitting idle | Usage reporting flags the key as low- or zero-use so you can reclaim the seat | Seat/usage reporting live |
| Leaver — someone exits | The leaver appears on the ingested feed. Because identity lives in the key's envelope, one revoke action kills every key bound to that person | Leaver feed ingested today; automatic revoke-on-exit is on the near-term roadmap |
One caveat stated plainly, because the whole point of this page is honesty: the leaver feed is ingested; automatic revocation triggered by it is on our near-term roadmap, not shipped. Today you get the full joiner-and-mover picture and one-action revoke — because identity is carried in the token envelope, revoking a person removes every key bound to them in a single step. Automatic de-provisioning the moment the feed marks someone a leaver is coming, not done. We'd rather tell you that than let you find out on a renewal.
Why this beats SSO / IdP-only governance
Your first instinct is probably "we'll gate the AI tools behind SSO." That governs the door — who's allowed to log in. It does nothing about the spend on the other side.
An IdP knows a person is on a list. It doesn't know how many tokens they burned, on which project, against what budget, or when to stop them at a hard cap. When someone leaves, SSO can block the login — but it can't tell you what that person cost you last quarter, and it can't cap the API key an engineer minted outside the SSO flow entirely.
Per-employee AI governance puts identity in the token envelope, not just on an access list. Every call carries who it's for, so budget, attribution, and revoke are properties of the key itself — enforced at the gateway on every request, not implied by a login that happened hours ago. SSO answers "can they in?" This answers "how much, on whose behalf, and stop at the cap."
Where to start
If you own People-ops, this is your seat to claim — AI access folded into the same joiner-mover-leaver process you already run for every other kind of access. See the full picture on the for-people hub.
- Want to see what you're already spending, per person, before you buy anything? Run the free, no-key AI Spend Audit.
- Want to watch a governed key enforce a budget and refuse an over-cap call live? Book a demo.
Every employee already has AI. The only question is whether you can see it, budget it, and shut it off when they leave. You already do that for badges and laptops. Do it for AI.