What permissions should an AI agent have on a database?
Updated · DBShifts
Short answer
Only what the task needs: read-only access, specific tables and columns with everything else denied, sensitive columns masked, rows scoped to the user or tenant it serves, capped volume per request and per day, a token that expires, and changes only through named actions a person approves.
Key facts
- Least privilege for an AI agent is set per agent, not per database user.
- An assistant serving many people should read with one person's access at a time, not the union of everyone's.
- Row-level filters scope an agent to a tenant or user it can never see the identifier of.
- Volume limits are a permission too: how much of a table an agent may ever read.
- Expiring tokens limit how long a leaked credential is useful.
Scope by data
Start from nothing and add the tables and columns the task needs. Define curated views — 'active customers' with chosen columns and a forced filter — so agents query a stable name instead of raw tables.
Scope by person
When one assistant serves a whole company, giving it a single broad credential means every user reads with everyone's access, and the log names the application rather than the person. Exchange the application's token for a short-lived one bound to the person asking.
Scope by volume and time
Rows per request, requests per minute, rows per day, and the share of a table seen over a month. Add an expiry so a forgotten token stops working on its own.
Checklist
- 1
Read-only by default
- 2
Allowlist tables and columns per agent; deny everything else
- 3
Mask sensitive columns and keep unmasking for people
- 4
Force row filters for tenant or user scope
- 5
Bind assistants to the person they serve with short-lived tokens
- 6
Cap rows, rate and cumulative reads
- 7
Set expiry and, where possible, an IP allowlist
- 8
Allow changes only as approved, undoable actions
Common mistakes
Copying a human's permissions to an agent
People use judgement and get tired; agents do neither. An agent should have narrower access than the person it helps.
Broad access 'so it can answer anything'
Every extra table is extra blast radius when the agent is wrong or steered. Add access when a real question needs it.
Tokens that never expire
Forgotten agents keep running. Expiry turns a forgotten token into a closed one.
How DBShifts does it
- DBShifts policies are default-deny table and column allowlists with forced row filters and named views.
- A per-token scope can only narrow the gateway's policy, never widen it.
- Delegation exchanges an application's token for a short-lived one bound to a single end user, so access and the audit log follow the person.
- Limits cover rows per request, requests per minute, daily and monthly budgets, and an exposure cap on the share of a table one token may see.
- Tokens can expire and be bound to an IP allowlist; changes happen only through approved actions with undo.
Questions people also ask
Should every agent have its own token?
Yes. Separate tokens give you separate limits, separate audit trails and the ability to stop one agent without touching the others.
Can an agent ever write?
Only through named, parameterised actions it proposes and a person approves. Reads stay read-only.
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.