Do Not Give an AI Agent the Keys to Everything: Build a Permission Budget

Featured image: conceptual AI-generated illustration; not documentary evidence.

An AI assistant that drafts an email creates text. An AI agent connected to your inbox may be able to find recipients, attach files and press send. Add a calendar, cloud drive, customer database and payment account, and a single instruction can travel across several systems before a person sees the consequences.

That does not make agents inherently unsafe. It changes the unit of risk. The important question is no longer only, “Can the model produce a wrong answer?” It is also, “What can this system do when it is wrong, misled or misunderstood?”

The practical response is a permission budget: a deliberately small package of data, tools, money, time and authority that an agent may use for one defined purpose. The agent receives enough power to complete the task, but not enough to turn one mistake into an unlimited chain of actions.

Capability is not authority

A system may be capable of writing a refund message, calling a commerce API and updating a customer record. That does not mean it should have standing authority to do all three for every customer.

Security practice has long used the principle of least privilege: give a user or process only the access needed for its current function. The same logic matters for agents, but with extra attention to sequences. An agent can combine individually ordinary steps—read a message, retrieve a document, call a tool and send a reply—into an outcome nobody explicitly reviewed.

OWASP’s guidance on “excessive agency” identifies three broad sources of risk: too much functionality, too many permissions and too much autonomy. Its recommended controls include minimising tools, limiting permissions, executing actions in the user’s context where appropriate and requiring approval for high-impact operations. NIST’s Generative AI Profile likewise frames risk management as a continuous process of governing, mapping, measuring and managing—not a one-off trust decision.

The five parts of a permission budget

1. Data scope: what may the agent see?

Grant access to the smallest relevant collection, folder, account or record set. An agent preparing a quarterly supplier summary may need selected invoices, not the entire company drive. A travel-planning agent may need dates, budget and destination preferences, not unrestricted access to private messages.

Separate “read” from “write”. Reading a calendar is different from changing it. Viewing a customer profile is different from exporting the database. Sensitive fields—health information, identity documents, children’s data, passwords and financial credentials—deserve explicit justification rather than convenient default access.

2. Tool scope: what may it operate?

List each connected tool and the exact operations permitted. “Email access” is too vague. Can the agent search mail, read attachments, create drafts, send internally, send externally, delete messages or change forwarding rules? Each verb represents a different consequence.

Disable tools that are irrelevant to the active task. A research agent should not inherit payment capability simply because both functions exist inside the same workspace. Tool access should follow the job, not the maximum capability of the platform.

3. Value scope: how much can it commit?

Where money, credits, advertising budgets, inventory or contractual obligations are involved, set hard numerical limits. Useful controls include a maximum per transaction, a daily ceiling, approved merchants, an allowed currency and a ban on subscriptions or recurring commitments unless separately authorised.

The same idea applies beyond money. Limit the number of emails, files, accounts, posts or records an agent can change in one run. A bulk operation should not be treated like a single low-risk click merely because it uses one command.

4. Time scope: when does authority expire?

Permanent access is convenient and dangerous. Prefer credentials or sessions that expire after the job or a short window. If an agent needs recurring access, review it periodically and remove permissions that have become unnecessary.

Time limits also reduce the damage from forgotten integrations. A tool authorised for one campaign should not quietly remain connected months after the campaign ends.

5. Decision scope: which actions require a person?

Set approval gates according to consequence, not inconvenience. Drafting can often run automatically; sending to a new external recipient may require review. Comparing products can be autonomous; completing a purchase may require confirmation. Preparing code is different from deploying it to production.

A good gate shows the reviewer what will happen, what data will be used, who or what will be affected, and whether the action can be reversed. A button labelled “Continue” without a meaningful preview is not strong human oversight.

Build the boundary before writing the prompt

People often start with instructions—“book the cheapest suitable flight” or “clean up the customer list”—and consider permissions later. Reverse that order. Define the operating boundary first:

• Objective: the single outcome the agent is authorised to pursue.
• Allowed inputs: the precise records, folders or sources it may use.
• Allowed actions: the operations it may perform without further approval.
• Prohibited actions: deletion, external sending, purchases, credential changes or other excluded acts.
• Limits: time, quantity, money and recipient boundaries.
• Stop conditions: ambiguity, conflicting instructions, unexpected data or repeated failure.
• Evidence: the log, receipt or change summary the agent must return.

Natural-language instructions are still useful, but they should not be the only barrier. Wherever possible, enforce important restrictions in the surrounding system: account roles, API scopes, spending limits, isolated workspaces, allow-lists and approval workflows. A sentence saying “do not overspend” is weaker than a payment method that cannot exceed the authorised amount.

Prompt injection changes what “input” means

An agent may encounter instructions inside a webpage, email, document or tool response. Some may be malicious; others may simply conflict with the user’s goal. Because the model processes content and instructions through the same broad language interface, untrusted material can attempt to redirect its behaviour.

Permissions therefore matter even when prompts appear careful. Treat external content as data, not authority. Do not allow a document to expand the agent’s tools or approve a transaction. High-impact actions should depend on trusted policy and explicit user approval, not on text the agent found while working.

Logs must answer more than “what happened?”

An audit trail should record the initiating user, task, tools called, data accessed, approvals received, changes made and final outcome. It should also preserve failures and blocked attempts. A log that captures only successful actions hides the moments when a safety control did its job.

For reversible operations, provide a clear undo route. For irreversible ones—sending money, publishing information, deleting data or entering a contract—raise the approval standard and keep the authority narrow.

A two-minute pre-connection check

• Does this agent need the whole account or only one folder, record set or workspace?
• Can read and write permissions be separated?
• What is the maximum financial or operational loss from one bad action?
• Which actions require a preview and human approval?
• When will access expire, and how can it be revoked immediately?
• Will the system produce an understandable record of every action?

The ethical goal is not to make agents powerless. It is to make their power accountable. Trust should grow from bounded authority, visible actions and reliable controls—not from the hope that an intelligent system will always interpret a broad instruction exactly as intended.

Primary sources

• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1, July 2024).
• OWASP GenAI Security Project, LLM06:2025 Excessive Agency.
• National Institute of Standards and Technology, AI Risk Management Framework resources.