Copilot actions through your existing API: the permission model
How should AI copilot permissions work when the copilot can take actions?
Every copilot action maps to an existing permission-checked API call, so the copilot can never do what the user could not. Add a preview-and-confirm step, a policy gate for sensitive actions, an audit log and an eval suite, and a copilot that writes data becomes as safe as the UI it sits inside. Here is the model.
AI copilot permissions are simple to state and easy to get wrong: the copilot acts as the user, through the same API the user's clicks go through, with the same token and the same checks. It never gets a service account, never talks to the database directly, and never has a permission the person in front of it lacks. Every SaaS copilot we ship is built on that rule, and the rest of this article is the engineering that makes it hold.
We cover the threat model, the action framework, preview and confirm, policy gates for sensitive actions, audit and evaluation, and the build it takes.
Why AI copilot permissions need their own design
A copilot that only answers questions can be wrong; a copilot that takes actions can be harmful. It can reassign work, change prices, send messages, delete records or issue refunds. Two new risks arrive with actions. The first is the model misunderstanding the request and doing the wrong thing. The second is a user, or an attacker through a crafted input, persuading the model to do something the user is not allowed to do.
Both risks are contained by the same principle. If the copilot can only call APIs that already check the caller's permission, the worst a misunderstanding can do is what the user could have done by hand, and the worst an attacker can do is what that user's account already allows. The OWASP Top 10 for LLM applications lists excessive agency and prompt injection among the main risks; both are addressed by not granting the model any authority of its own.
The three permission models compared
| Model | How the copilot acts | Risk | Verdict |
|---|---|---|---|
| Service account with broad access | Copilot has its own credentials with wide scope | A misunderstanding or injection can touch any record; audit shows the bot, not the user | Never |
| Direct database access | Copilot writes SQL or ORM calls against the store | Bypasses every business rule and validation in the API | Never |
| User's token through existing API | Copilot calls the same endpoints the UI uses, as the user | Bounded by the user's permissions and the API's validation | Always |
The action framework
An action is a named operation the copilot may perform, backed by one existing API endpoint. Each action has a definition the model sees (name, description, parameters and their types), a handler that calls the endpoint with the user's token, and a risk class that decides how much confirmation it needs. The model chooses an action and fills its parameters; the framework validates them against the schema, checks the risk class and runs the handler.
Actions are defined by engineers, not discovered by the model. The copilot cannot invent an endpoint or call one that is not registered. If a job needs an operation the API does not expose, the API is extended first, with its own permission check, and only then does the action appear. This is the discipline that keeps the in-app copilot in a field-service product safe while it reassigns work across dispatchers.
Read, write, sensitive
Three risk classes cover nearly every product. Read actions (search, fetch, summarise) run without confirmation. Write actions (create, update, assign, close) show a preview and wait for the user to confirm. Sensitive actions (send to a customer, change money, delete, alter permissions) pass through a policy gate in addition to confirmation. The class is set on the action definition, not decided by the model.
Preview and confirm
Before any write action runs, the copilot shows what it is about to do in plain terms: which records, which fields, old value and new value, and how many items are affected. The user confirms or edits. For bulk operations the preview is a list the user can scan, and the confirmation names the count: "Reassign 14 tickets to Arjun". A confirmation that says "proceed?" without detail is not a confirmation.
Preview is also where most misunderstandings surface. If the model interpreted "Priya's tickets" as tickets created by Priya rather than assigned to her, the preview shows it and the user corrects it before anything changes. Cheap, visible and worth more than any prompt engineering.
Policy gates for sensitive actions
Some actions are safe only within limits: refunds below a threshold, discounts within a band, messages to customers only from templates, deletions only of records under a certain age. A policy gate is code that checks the action's parameters against those rules before the handler runs, and either allows, blocks with a reason, or routes to a human approver.
Policies live in code and configuration, not in the prompt. A prompt that says "never refund more than five thousand" is a suggestion; a gate that rejects the parameter is a rule. Our policy-gated actions article goes deeper, and the same gates serve customer service agents and copilots alike.
Prompt injection and untrusted content
Copilots read content the user did not write: emails, tickets, documents, web pages. Any of that can contain instructions aimed at the model. The defence is layered. The permission model bounds the damage. The action framework prevents unregistered operations. Content from external sources is marked as data in the prompt, never as instructions. And sensitive actions require confirmation from a person, which an injected instruction cannot supply. Treat every retrieved document as hostile and the design holds.
Audit log and evaluation
Every action, attempted or completed, is logged with the user, the tenant, the action name, the parameters, the preview shown, the confirmation given, the policy decision and the API response. The log answers "who changed this and why" for a compliance reviewer and "what went wrong" for an engineer. It is also the source of eval cases: every action a user corrected at preview becomes a test.
The eval suite for actions scores whether the model chose the right action with the right parameters for a set of real requests, and includes negative cases: requests that should be refused, injected instructions that should be ignored, and parameters outside policy that should be blocked. It runs on every prompt or model change, as described in evals: the practice that separates demos from products.
A worked example
A field-service SaaS company wanted dispatchers to reassign and reschedule work through the copilot. The existing API already enforced that a dispatcher could only touch jobs in their own region and could not move a job into a technician's day if it exceeded their hours. The copilot was given two write actions backed by those endpoints, called with the dispatcher's token.
Preview showed the affected jobs and the technician's resulting day; the dispatcher confirmed. A policy gate blocked reassignments that would breach a customer's contractual window and routed them to a supervisor. In beta, the audit log showed a handful of previews corrected by users, each of which became an eval case, and no action ever ran outside the dispatcher's existing permissions, because none could. The in-app copilot case study covers the rest of the product.
Team and timeline
The action framework, risk classes, preview UI, policy gate and audit log take a backend engineer and an AI engineer roughly three weeks on a product with a reasonable API, and are reused by every action added later. They are part of the SaaS copilot scope from $19,500 / ₹12.8L. Where the API lacks endpoints for the actions users want, the API development and integrations service builds them first. Security review of the permission model can be folded into a ten-day Sprint Zero. Prices are on the pricing page, and our security practices on the security page.
Before you start: a checklist
- Confirm every candidate action has an existing API endpoint with a permission check
- Decide that the copilot calls APIs with the user's token, never its own
- Register actions explicitly with schema, handler and risk class
- Design the preview format for single and bulk writes
- Write policy gates in code for sensitive actions, with a human-approval route
- Mark all retrieved content as data, not instructions, in prompts
- Log every attempted action with parameters, preview, confirmation and outcome
- Build an eval suite with negative and injection cases before launch
Glossary
- Action: a named operation the copilot may perform, backed by one existing API endpoint
- Risk class: read, write or sensitive; decides confirmation and gating
- Preview and confirm: showing the exact change before running a write action
- Policy gate: code that checks action parameters against business rules before execution
- Prompt injection: instructions hidden in content the model reads, intended to redirect it
- Excessive agency: granting a model more authority than the task requires
Related reading
How to build an AI agent that is safe to run unattended, MCP explained: how agents safely use internal tools and adding AI to an existing product without a rewrite build on this model. The OWASP LLM security project is the primary reference for the threat categories.
Give the copilot no authority of its own, and it can never do more harm than a user with the same login; everything else in this article is there to make that sentence true.
Frequently asked questions
Should an AI copilot have its own service account?
▾
No. It should call your existing APIs with the signed-in user's token so every action is bounded by that user's permissions and the API's validation. A service account gives the model authority the user never had.
How do we stop a copilot doing something harmful?
▾
Register actions explicitly, classify them as read, write or sensitive, show a preview before writes, gate sensitive actions with code-level policy, and log everything. A person confirms anything that changes data.
Does prompt injection matter for copilots?
▾
Yes, because copilots read emails, tickets and documents that may contain hidden instructions. Bound the damage with the permission model, treat retrieved content as data, and require human confirmation for sensitive actions.