Agent permissions: what an AI agent should be allowed to do, and how to say so
An AI agent that can query your database and post to Slack is useful. An AI agent that can query your database and post to Slack with the same standing as a senior engineer is a liability. The difference between the two is not the model; it is the permission system around it.
Three verbs, not one
Most permission systems for people have one question: can this person do this thing? Agents need three, because the agent is acting on somebody’s behalf and the interesting cases are the ones where the person and the agent should not have identical authority.
- Read. Which records, logs and metrics can the agent look at when answering this person? Usually the same set the person could see themselves — and no wider, however helpful it would be.
- Propose. Which changes can the agent draft? A retry, a row update, a Slack message. A proposal is not an action. It is a specific, reviewable description of what would happen.
- Act. Which proposals can run, and on whose say-so? Some on the person’s own confirmation. Some on a manager’s. Some never.
Separating the three is what makes the rest tractable. An agent that can read everything but propose nothing is a search box. An agent that can propose anything but act on nothing is a very good drafting assistant. The permission system is how you draw the line between them per person, per system.
Permissions belong to the person, not the prompt
The tempting shortcut is to put the rules in the system prompt: “only update rows the user owns.” That is a request, not a control. A prompt can be argued with, and a model can be wrong about what it was told. The rule has to be enforced by the code that executes the action, against the identity of the person asking, and the model should never have a path around it.
In GlowForm every tool call goes through one runner, and the runner’s first step is a pure authorization decision — a function of the policy snapshot and the request, with no I/O and no clock — before any connector opens a credential. The chat planner proposes; it never executes, approves or publishes. That is not a prompt-engineering choice. It is the shape of the code.
Scope is the whole game
Saying an operations team may “retry provisioning” is not a permission until you say for which customers, in which environment, and how often. Row scope (only records assigned to you), environment (staging yes, production with approval), and a daily cap on a policy are the difference between a permission and a blank cheque. Write permissions down at that resolution or you have not written them down.
The approval is a permission too
Requiring a manager to approve a production retry is itself a rule with a scope: who counts as a manager, for which systems, and what they see when they decide. Treat the approval path as part of the permission model, not as a UI afterthought, and record the decision in the same audit trail as the action it unlocked.
Where to start
- Start with read-only. Let the agent answer questions from the systems people already have access to. You learn what people actually ask.
- Add propose-only next. Let it draft the retry, the row update, the message — and show the draft. People will tell you which drafts they trust.
- Grant act permissions one operation at a time, narrowest scope first, with an approval on anything that touches production or money.
That order is slower than turning everything on. It is also the order in which nobody loses a weekend.