AI assistants are moving beyond answering questions and drafting text. Some can search files, organise calendars, update records, use connected tools and prepare or send messages. That creates a practical question for anyone using them: what should an AI system be allowed to do without asking first?
The answer should not be “everything the user can do”. An AI assistant needs a limited form of digital delegation: authority to perform defined tasks within clear boundaries for data, money, accounts and consequential decisions.
This is the central issue in AI agent permissions. The challenge is giving an assistant enough authority to reduce routine work without giving it enough power to create private, costly or difficult-to-reverse mistakes.
Why ordinary app permissions are not enough
People already use software permissions. A calendar app may request access to read and edit events. A workplace application may use a company login to access documents available to an employee’s role.
Those controls remain important, but AI agents introduce an additional problem. A conventional application generally performs a defined function. An AI agent may interpret a broad request, select tools and make intermediate choices while pursuing a goal.
A request such as “organise next week’s client meetings” could involve reading calendars, finding contacts, checking time zones, drafting messages and sending invitations. Each action may appear routine, but together they can have meaningful consequences. The agent could misunderstand priorities, use outdated information, invite the wrong person or include information that should have remained internal.
People make similar mistakes, but software can act quickly across several connected services. A permissions model for AI agents therefore needs to govern not only access, but also actions taken when the system encounters ambiguity or incomplete information.
What digital delegation means in practice
Digital delegation means authorising software to act on someone’s behalf within a defined area. The level of authority can vary considerably.
At the lower-risk end, an assistant might sort documents into folders, identify duplicate files or prepare a customer-reply draft. These tasks can save time without making an external commitment.
At a higher level, it might send meeting invitations, update customer details, reorder supplies, publish content or process a refund. Such tasks may be useful, but they can affect other people, finances or official records.
Many productivity and enterprise platforms offer AI features that work with connected email, documents, calendars and business data, subject to the permissions configured by an organisation. Tool-using systems may also call application programming interfaces, or APIs, which allow one piece of software to request a defined action from another.
The important distinction is that access should not become a blank cheque. Permission to read a calendar does not automatically justify permission to contact every attendee. Access to a purchasing system does not necessarily justify making a purchase.
The four boundaries every AI agent should have
A safer approach to AI workflow automation separates different forms of authority. Rather than deciding whether an agent is broadly “trusted”, users and organisations should define what it can access, what it can do and under which conditions.
1. Data boundaries
Data boundaries specify what information an agent may read, search, copy or summarise. An assistant helping with a project may need access to that project’s folder, but not payroll records, private medical documents or an executive’s mailbox.
This follows the security principle of least privilege: give a system only the access needed for its task. Excessive permissions can increase the impact of an error, compromised account or malicious instruction.
2. Action boundaries
Action boundaries define what an agent may change or communicate. Reading a document, creating a draft and sending that draft are different levels of authority. So are viewing a customer record, editing it and deleting it.
A well-designed system should make these distinctions visible. “Can access customer data” is too broad if it does not clarify whether the assistant can export, amend or erase that data.
3. Spending and resource limits
Where an agent can purchase goods, issue refunds, use paid services or consume computing resources, it needs limits. These may include a maximum amount per transaction, a monthly cap, approved suppliers or a rule requiring approval for a new vendor.
Resource limits also matter outside finance. A system that can send thousands of emails, create large numbers of support tickets or launch costly computing jobs can cause harm without making a conventional purchase.
4. Time and context limits
Permissions should expire when a task ends. An assistant helping to arrange a conference does not necessarily need permanent access to calendars and contact lists. An agent authorised to prepare a report should not automatically retain authority to edit underlying records weeks later.
Context matters as well. An agent may be allowed to schedule internal meetings but not meetings with external partners. It may be permitted to act during a supervised work session but not overnight. These limits can reduce the risk that a temporary connection becomes broad, lasting access.
Permission should rise with the risk
Not every action needs the same level of oversight. A practical model matches controls to the likely impact of a mistake.
- Low-risk tasks: Summarising information, sorting files, tagging records, suggesting replies and creating drafts may be suitable for automation when data access is limited.
- Moderate-risk tasks: Updating routine internal records, scheduling standard meetings or preparing customer responses may need rules, sampling checks or approval when unusual conditions arise.
- High-risk tasks: Deleting information, changing account security settings, sharing sensitive data, approving payments, making legal or financial commitments, or communicating with regulators should normally require explicit human confirmation.
The key is to distinguish minor mistakes from high-impact ones. Misfiling a document may be easy to correct. Cancelling a contract, transferring funds or sending a legally significant message may not be.
This is where conventional software permissions can be too coarse. A single “write access” permission may cover harmless formatting changes as well as deletion of a critical record. AI agent security benefits from more detailed categories of action.
When an agent should ask before acting
Confirmation rules require balance. If an assistant asks for approval before every file rename or calendar entry, it stops being useful. If it never asks, convenience can come at the expense of control.
A better approach is to reserve approval prompts for actions that are irreversible, unusual, expensive, externally visible or outside the original request. An agent could prepare meeting invitations automatically, then show the proposed recipients and times before sending them.
Approval prompts should explain the action in plain language. “Approve API call” is less useful than “Send this message to 14 external contacts and add a video link to their calendars.” The person approving the action should be able to understand its likely effect without reading technical logs.
Thresholds can also help. An assistant may be allowed to reorder regularly purchased supplies below a set amount, while larger purchases require approval. It may update records that meet a clear rule but flag ambiguous cases for review.
There is no universal threshold. A small payment may be insignificant for one organisation and material for another. The goal is adjustable control rather than a single safety setting.
Audit trails make delegation accountable
Once an AI system can act, users need more than a final result. They need a readable record of what happened. An audit trail should show what information the agent used, which tools it invoked, what it changed, what it sent and whether an action failed or was blocked.
Logging is common in security-sensitive systems, but agent activity should also be understandable to non-specialists. A useful history might state that an assistant searched a shared folder, found three invoices matching a request, created a draft expense report and paused because one invoice did not match the named supplier.
That record can help users identify errors, help organisations investigate incidents and support improvements to rules and workflows. It also challenges the assumption that an agent’s work is too complex to inspect.
Where feasible, records should capture uncertainty, failed attempts and escalation decisions. AI systems can misinterpret requests, generate incorrect information or select an unsuitable tool. A record that shows those limits is more useful than one that presents an incomplete picture of success.
Reversible automation is safer automation
The safest action is often not the one an agent completes immediately, but the one it prepares in a form that can be reviewed, tested or undone.
Reversible automation can include previews before publication, draft messages instead of sent messages, holding periods before deletion, version history for edited documents and an undo option for routine changes. In business settings, an agent may work in a sandbox: a separate testing environment where actions do not affect live customer accounts or production systems.
Staged execution is another useful pattern. An agent might classify 20 records, show the result and proceed with the remainder only after a person accepts it. This is slower than unrestricted automation, but it can limit the effects of a systematic error.
Not every action can be fully reversed. A message may already have been read or copied. A payment may only be cancelled before processing. Sensitive information cannot be made private again once sent to the wrong recipient. Those actions deserve stronger controls before they occur.
Why untrusted content can confuse an AI agent
A major AI automation risk arises because language models process instructions and ordinary content in similar forms. A webpage, email, document or customer message may contain text intended to influence the agent’s behaviour.
Security researchers commonly describe this family of problems as prompt injection. Indirect prompt injection can occur when an agent encounters untrusted content containing a hidden or visible instruction and treats it as an authorised command. For a tool-using system, the risk is not limited to an incorrect answer. It may lead to an inappropriate search, message, data request or attempted action.
OWASP, which publishes widely used application-security guidance, identifies prompt injection as a key risk for applications using large language models. The practical response is not to assume that an AI model can reliably distinguish trusted instructions from all hostile or irrelevant text.
Instead, systems should separate user-approved goals from external content, restrict available tools, require confirmation for sensitive actions and avoid broad access merely because an agent reads the web or a mailbox. External content should be treated cautiously, particularly when it could trigger an action.
Responsibility does not disappear when software acts
When an agent makes a mistake, responsibility may be shared. A user may have granted overly broad access. An employer may have deployed the system without suitable testing, training or oversight. A provider may have designed weak safeguards. A connected service may have failed to enforce its access controls.
Human approval does not automatically settle the issue. A person clicking “approve” may not have received enough information to make a meaningful decision, especially if the interface obscures consequences behind technical language. Equally, an organisation should not assume that an employee can provide effective oversight if the system gives them little practical ability to review its actions.
Legal responsibilities vary by country, sector and use case. Privacy and data-protection rules may apply when personal information is processed, and regulated industries can have additional requirements for records, access control and human review. Organisations should seek legal and compliance advice for high-impact deployments.
Personal assistants and workplace agents need different safeguards
An individual may decide that the convenience of an assistant sorting personal files outweighs the risk of an occasional error. Even then, the user should understand whether the system can read sensitive folders, retain data or connect to email and cloud storage.
Workplace use is more complex because the effects can extend beyond the person enabling the tool. An agent may handle customer information, trade secrets, employee records or regulated data. It may also operate with permissions inherited from a powerful employee account.
For employers, AI agent permissions should fit within existing identity and access management practices. This can include separate accounts where possible, role-based access, time-limited credentials, approval workflows and regular access reviews. Authorisation approaches such as OAuth scopes can limit what a connected application may do, but organisations must still decide whether a requested scope is too broad for an autonomous or semi-autonomous agent.
A practical checklist before enabling an AI agent
- What can it read? Identify the folders, messages, databases and personal information it can access.
- What can it change? Separate viewing, drafting, editing, sending, deleting and publishing permissions.
- Can it spend money or consume paid resources? Set transaction, supplier and usage limits.
- When must it ask for approval? Require confirmation for external communication, sensitive data, unusual actions and irreversible changes.
- Can its actions be undone? Look for previews, drafts, version history, deletion recovery and testing environments.
- Is there a clear activity record? Ensure a person can review what the agent did and why it attempted an action.
- How is access removed? Check whether permissions can be revoked quickly if a service is compromised or the tool is no longer needed.
- How does it handle untrusted content? Ask what happens when it encounters instructions in emails, documents or webpages.
What to watch as agent controls develop
Technology companies, security researchers and standards groups are developing approaches to agent identity, delegated authority, access control and records of actions. These efforts include machine-readable permissions, stronger identity systems and more detailed policies for tool use.
However, the field is still developing. Many approaches remain vendor features, technical frameworks or early industry initiatives rather than universally adopted standards. A permission granted in one service may not translate cleanly to another.
That uncertainty is a reason for caution, not paralysis. The core safeguards are familiar from other areas of computing: least privilege, clear consent, separation of duties, logging, testing and the ability to revoke access. AI agents make these principles more important because they combine access with flexible interpretation.
The long-term value of AI assistants may depend less on making them appear fully independent than on making their authority visible and adjustable. A trustworthy agent is not the one that can do everything. It is the one that makes it easy for people to decide, in advance and in context, what it may do on their behalf.
Image by Mikhail Nilov on Pexels.