How do I give each employee's AI assistant their own data permissions?
Updated · DBShifts
Short answer
Don't give the assistant one shared credential. Have each person sign in from their own AI client, so the client receives a token bound to them, and work out what they may read from their own grants or identity-provider groups. Re-check that on every request, so removing someone ends their access at once, and log every read under their name.
Key facts
- One shared token makes an AI assistant read with the union of every user's access.
- OAuth 2.1 with PKCE lets an MCP client obtain a token bound to the person who signed in.
- Group rules from an identity provider map whole teams to access without listing every person.
- Access that is re-checked on every request ends the moment a person or a group rule is removed.
- An audit entry that names the person answers who saw the data, not just which tool fetched it.
Why one shared token fails
An assistant that serves a whole company with one service credential can read whatever that credential can, for whoever happens to be asking. A sales rep's question runs with finance's access because the assistant has it. Security calls this a confused deputy: the tool has more authority than any of its users and no way to tell whose authority it is exercising.
The audit log makes it worse. It records the assistant, not the employee, so the one question an investigation needs answered — who saw this record — has no answer.
Sign-in per person
The Model Context Protocol defines how a client signs a person in to a server with OAuth 2.1. The client finds the server's authorization metadata, registers itself, sends the person to sign in and approve, and exchanges the result for a token. PKCE protects the exchange, and the token is bound to that one server, so it cannot be replayed against another.
The token stands for the person. What it can read is the person's access, not the client's.
Groups, freshness and removal
Listing every employee does not scale; mapping identity-provider groups to access does. Two details decide whether that is safe: trust group claims only from your own identity provider, and treat them as only as fresh as the person's last sign-in through it.
Then evaluate access on every request rather than once at sign-in. A person who leaves, changes team or loses a group should lose access on their next call, without anyone having to find and revoke a token.
Checklist
- 1
Each person signs in; there is no shared assistant credential
- 2
Tokens are bound to one server, short-lived, with rotating refresh tokens
- 3
Default-deny: someone not listed and in no mapped group gets nothing
- 4
Group claims are trusted only from your own identity provider
- 5
Access is re-evaluated on every request, not only at sign-in
- 6
Every read is logged under the person's identity
- 7
Owners can see each connected client and disconnect it
Common mistakes
Giving the assistant's service account everything
It is the quickest setup and it makes every user as powerful as the most privileged one, with an audit log that names nobody.
Trusting groups from any identity provider
A group is only meaningful if your organisation asserted it. A rule that accepts the same group name from an identity provider someone else configured can be satisfied by anyone.
Checking access only at sign-in
Tokens and refresh tokens outlive org-chart changes. If the check happens once, a person who moved team keeps their old access until the token happens to expire.
How DBShifts does it
- Each DBShifts Agent Gateway has its own MCP URL that MCP clients can sign in to with OAuth 2.1: discovery metadata (RFC 9728 and RFC 8414), dynamic client registration, PKCE with S256, and tokens bound to that one gateway.
- A person gets the gateway policy if they own the gateway, the scope set for their email if the owner listed them, or the first matching rule for their identity-provider group; anyone else is refused.
- Groups come from SAML single sign-on on a workspace the gateway owner owns, and count only if the person signed in through it recently enough (24 hours by default).
- Who gets what is worked out again on every request, so removing a person or a group rule ends their access on the next call. Refresh tokens rotate, and a reused one revokes the connection.
- Reads are logged under the person's email; the owner sees every connected client and can disconnect it.
Questions people also ask
Which AI clients can sign in this way?
Clients that implement the MCP authorization flow: OAuth 2.1 with dynamic client registration and PKCE. A client that can only send a fixed token can still use a scoped agent token instead.
Does the AI provider see my users' passwords?
No. People sign in on DBShifts' own page; the client only receives a token for one gateway, and can be disconnected at any time.
What happens when someone leaves the company?
Remove them from the gateway's list or from the mapped group. Their next request is refused. Group membership also lapses on its own once it is older than the allowed age since their last single sign-on.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free18 answers in this series. See all.