AI agents need fewer permissions than you think

The risk changes when AI can take action

A chatbot that produces a wrong paragraph can mislead a user; an agent connected to email, files, databases or payment tools can also change the world around that user. The key distinction is not whether a system is called an agent. It is whether it can invoke tools, access private information, persist state or trigger consequential actions without a person reviewing each step. Teams should inventory capabilities before discussing autonomy. List every tool, the data it can read, the changes it can make, the identity under which it runs and the systems that trust its output. This turns a vague AI risk conversation into a concrete access-control problem.

Apply least privilege to each task

Least privilege means granting only the access required for a defined task, for the shortest useful period. An agent that drafts a calendar invitation does not need permission to delete meetings, read every mailbox or administer the organisation's identity system. Separate read and write tools, narrow the available resource scope and create purpose-specific roles. Prefer a tool that can update one approved ticket over a general-purpose database credential. The model may decide which tool to call, but it should not decide the full extent of its own authority. Enforce permission boundaries in the application and underlying service, not only in the prompt.

Use scoped credentials and short lifetimes

Do not paste long-lived administrator tokens into prompts or store them in model-visible context. Keep credentials in a secrets manager or trusted backend, and expose narrow operations through a controlled tool layer. Where possible, use short-lived credentials, audience restrictions, resource scopes and explicit expiry. A tool should obtain only the secret needed for the current operation, and logs should never record the secret itself. If an agent session is compromised or manipulated, limited credentials reduce the damage window. Rotation and revocation procedures must be tested, because a token that cannot be quickly disabled turns a small prompt-level mistake into a broader incident.

Treat tool outputs as untrusted input

Agents often read emails, web pages, PDFs, tickets and code repositories. Those sources can contain instructions that attempt to override the agent's task, reveal secrets or induce it to call another tool. This is commonly discussed as prompt injection, but the practical lesson is broader: retrieved content is data, not authority. The tool layer should enforce access checks and permitted actions even if the model is persuaded to ignore its instructions. Keep trusted policy separate from retrieved text, restrict which sources can influence sensitive operations, and require confirmation before high-impact actions. No single prompt can reliably neutralise every hostile instruction embedded in content.

Build approval gates around impact

Not every tool call needs human approval. Requiring a person to confirm every harmless read can make a system unusable, while allowing every write to proceed automatically can be reckless. Classify actions by impact and reversibility. Searching an approved knowledge base may be low risk; sending an external email, changing a customer account, issuing a refund or deleting records may need confirmation. Show the reviewer the proposed action, relevant source information, target, expected effect and a way to cancel. Approval should bind to the exact action being approved. If the agent changes the recipient, amount or payload after approval, request approval again.

Make the application enforce the policy

A common mistake is to ask the model to remember a permission rule and then give it a powerful generic tool. Instead, implement policy checks in ordinary application code. Validate the user, resource, requested operation, allowed fields and current workflow state before executing a call. Use allowlists rather than broad blocklists, and reject unknown actions by default. Where possible, have the model propose a structured action that a deterministic service validates. Keep the model away from direct database administration, shell access and unrestricted network access unless the use case genuinely requires them and robust isolation is in place.

Limit chained actions and spending

Agents can combine individually permitted steps into an unexpected sequence. A tool that reads an invoice and another that creates a payment may together create a financial action no single tool description intended. Define budgets, step limits, rate limits, timeouts and destination restrictions. Add idempotency keys for actions that might be retried, and make the system detect duplicate requests. For external calls, constrain domains and methods rather than offering open-ended network access. Track cumulative effects across a session, not only the validity of each isolated call. A sensible limit can turn an unexpected loop into a contained inconvenience instead of a runaway bill or a flood of messages.

Keep an audit trail that answers who did what

A useful log records the initiating user, agent session, tool name, target resource, validated parameters, policy decision, approval reference, result and timestamp. Redact credentials and unnecessary personal data. Store enough information to reconstruct an incident without creating a second repository of sensitive content. Make clear whether an action was proposed, approved, executed or rolled back. Monitoring should flag repeated denials, unusual destinations, sudden increases in tool use and attempts to access out-of-scope resources. Logs matter only if somebody reviews the signals and knows how to respond. Assign an owner for alerts and define which events require immediate containment.

Test failure paths before production

Test more than the happy path. Try a malicious document, a stale credential, a revoked permission, an unavailable tool, an ambiguous request, a repeated action and a response that contradicts the tool result. Confirm that the agent stops safely when a tool returns incomplete information. Verify that approval cannot be bypassed through a retry or a second tool. Test whether a user can make the agent act on another user's records by changing identifiers in the prompt. Keep these cases in a regression suite and rerun them after changing prompts, tools, model versions or access rules. A successful demo shows possibility; these tests show whether the system can fail safely.

Design recovery and a kill switch

Before granting an agent write access, decide how to stop it and recover from mistakes. Provide a way to revoke sessions, disable a tool, pause a workflow and identify actions that can be reversed. For irreversible actions, add stronger approval and staged execution. Backups and transaction logs can support recovery, but they do not replace prevention. Communicate to operators what a shutdown does: whether queued work is cancelled, whether active calls finish and who can restore service. Practice the procedure with the people who will be on call. An emergency control that nobody has tested is only a hopeful diagram.

Choose autonomy by evidence

The right question is not whether an agent can run without a human. It is which specific actions it can perform safely under defined conditions. Start with read-only access, measure task success and failure severity, then expand permissions one capability at a time. Record the evidence required for each increase in autonomy, including observed error rates, recovery time and the quality of human review. Keep the ability to reduce permissions when the system or environment changes. An agent becomes trustworthy through narrow authority, observable behaviour and tested controls, not through confident language or a long list of integrations.