Governing AI Access

I. The default-admin problem

Most team AI tools ship with exactly one level of access beyond the owner: member. Invite someone to help monitor spend, and they can now also replace the provider API keys that actually call OpenAI or Anthropic, remove other members from the account, and change the plan or billing. None of that is a deliberate grant — it is what “member” means when there is no finer distinction underneath it. The practical effect is that access decisions get made once, at invite time, by accident, and never revisited, because there is nothing to revisit them into. A role system exists to make that decision explicit — what can this person change, not just what can they see — and to make it something the owner actually chooses rather than inherits from the shape of the product.

II. A policy table enforced on the server, not the UI

Five roles exist — Owner, Admin, Developer, Finance, and Viewer — and each one is checked against a single policy table before a request ever reaches its handler, on every management API call, not just in the dashboard that renders around it. That ordering matters more than it sounds: a UI that merely hides a button a role “shouldn't” use is a convenience, not a boundary, because anyone who can see the API can call it directly. Enforcing on the server means the dashboard and a raw API call get exactly the same answer. A Viewer attempting to change provider credentials gets a structured 403 naming the permission it lacked and the role it has — not a silently disabled button it never sees the reasoning for.

The roles split cleanly by function rather than by seniority: a Developer can manage routing rules, the Auto Router, guardrails, and proxy keys, but not provider credentials, billing, or SSO configuration. Finance can create budgets, run chargeback mappings, and export data, but not touch routing or credentials at all. Only the Owner can grant or remove the Admin role itself, so an Admin can never promote themselves or another account to Admin — a single privileged action that stays with exactly one person. And a new endpoint added to the product without an explicit classification defaults to admin-only for anything that changes state, with a build-time test that fails if a state-changing route is ever left relying on that default — so a forgotten classification fails closed, not open.

III. Signing in without a shared password

A role system controls what someone can do once they are in. It says nothing about how they got in — and a separate, forgettable password per SaaS tool is exactly the credential most likely to be reused, phished, or simply left active after someone leaves. SAML SSO lets an organization route sign-in through the identity provider it already runs — Okta, Microsoft Entra ID, Google Workspace, or any SAML 2.0 provider — so access to Cognocient rises and falls with access to that one identity system instead of a separate credential no one is tracking.

The setup has one non-obvious but essential step: before any email domain is routed to an identity provider, its owner has to prove they control it, with a DNS TXT record. Skip that proof and anyone could register a company's domain and capture its employees' sign-in as their own. Only a domain verified this way routes to that organization's identity provider, and it can belong to exactly one organization at a time — public domains such as gmail.com can never be claimed by anyone. An organization can also require SSO for every member, with one deliberate exception: the account Owner keeps normal sign-in as break-glass access, so a misconfigured or briefly unreachable identity provider can never lock the organization out of its own account.

IV. Joiners, movers, and leavers, automatically

SSO on its own answers who can sign in; it does not, by itself, keep the roster in sync with who is actually still employed. Left alone, that roster drifts — someone leaves the company and keeps a working Cognocient session until an administrator remembers to remove them by hand. SCIM provisioning closes that gap by connecting the identity provider directly to team membership: creating, updating, and deactivating people in the identity provider does the same in Cognocient, immediately, without a human in the loop for the routine case.

The mapping is deliberately narrow. Three role groups exist to sync into — developer, finance, viewer — and there is no admin group at all, on purpose: admin is the one role that can change security settings, so a SCIM request asking for it is refused outright rather than silently downgraded, and only the account Owner can grant it, inside the application itself. Deactivating or deleting someone in the identity provider ends their Cognocient access immediately, and they cannot reactivate themselves by signing in with SSO afterward — an administrator has to deliberately reprovision them. Every one of these changes is recorded with the actor shown as the identity provider itself, not a person, so it is clear later which changes were automatic and which were made by hand.

V. Authenticating calls, not just people

SSO and SCIM govern people signing into the dashboard. A separate, older problem sits underneath the application code itself: a long-lived proxy API key, pasted into a config file or an environment variable, that never expires on its own and is the credential most likely to end up somewhere it shouldn't — a log line, a client-side bundle, a forked repository. JWT authentication replaces that static credential with a short-lived token minted by the organization's own identity provider for a specific user or workload, verified on every call rather than trusted indefinitely once issued.

Verification is intentionally strict: only asymmetric signing algorithms are accepted — RS, PS, and ES families — while alg: none and every symmetric HMAC algorithm are rejected outright, closing the classic algorithm-confusion attack where a token is re-signed with a public key treated as a shared secret. The issuer and audience must match exactly what was registered, the token must carry an expiry, and signing keys are fetched from the identity provider's own JWKS endpoint — which must be public HTTPS, so an internal or private address cannot be registered as a source of trust. A useful side effect: claims already present in the token — user, department, project — become cost attribution automatically, with explicit X-Cost-* headers still taking precedence whenever an application sends them.

VI. Proving it after the fact

Every control above answers a question about the moment access is used. None of them, on its own, answers a question asked afterward — who changed this budget last month, and was it actually them. The audit log is the record that makes the first four controls provable rather than merely enforced: every state-changing action across the account, and every denied attempt, is written with the actor, their role at the time, a timestamp, the source IP, and the result. A Viewer repeatedly attempting to change provider credentials is exactly the kind of denied attempt worth surfacing on its own, not just a successful change.

The log is deliberately narrow about what it stores: it records that a provider key was saved, not the key itself; that SSO was reconfigured, not the identity provider's metadata — request bodies are excluded entirely because they are exactly where secrets end up. It is append-only from the application, with no edit or delete path in the product, kept for 400 days — the longest window it can be queried or exported across — with one exception: billing lifecycle events are retained for seven years. Entries generated by SCIM or SSO provisioning are attributed to the identity provider as the actor, so it stays clear which changes were automatic and which were made by a person directly.

VII. One governance layer, not four separate tools

Roles decide what a person can change once they are in. SSO decides how they get in, routed through an identity provider the organization already trusts. SCIM keeps who is “in” current with who is actually still employed, without a human remembering to act on every departure. JWT authentication extends the same idea to application code, replacing a static key that never expires with a token an identity provider issues and can revoke. None of the four substitutes for the others — SSO without SCIM still requires someone to notice a departure and act on it by hand; roles without an audit log are enforced but not provable after the fact. Run together, they turn “who can do what to our AI spend, and can we prove it” from an assumption into an answer.