An AI Agent Should Not Inherit Your Entire Digital Life

The most consequential moment in an AI agent demo may not be when it completes a task. It may be the permission screen that appeared just before the demonstration began.

Access to email. Access to documents. Permission to edit a calendar, send messages, or update customer records. Each request can sound reasonable in isolation. Together, they can turn a useful assistant into software with more authority than its assignment requires.

My view is straightforward: we should judge AI agents as much by the authority they can safely do without as by the tasks they can perform. A convincing demo proves capability under selected conditions. It does not establish that the agent deserves standing access to an organisation’s systems.

A small task should come with small permissions

Consider an agent asked to arrange a meeting with a supplier. It may need calendar availability, the supplier’s address, and permission to create an invitation. That does not automatically justify access to years of email or the ability to send arbitrary attachments.

The principle of least privilege is familiar in security engineering. Agents make it newly urgent because they interpret open-ended requests and may encounter untrusted material while carrying them out. An email, webpage, or document can contain instructions that compete with the user’s actual intent.

That is where prompt injection attacks matter. A malicious document might tell an agent to retrieve confidential information and forward it elsewhere. Whether the attempt succeeds depends on the system, its safeguards, and the permissions available. But the underlying distinction is essential: content an agent reads must not automatically become authority it obeys.

Restricting permissions will not eliminate every attack. It can, however, reduce what a successful attack is able to do.

Approval needs to mean something

“Keep a human in the loop” sounds reassuring until the human faces a stream of vague confirmation boxes. Clicking “Allow” twenty times is not the same as exercising informed oversight.

A meaningful approval should expose the proposed consequence. Before an external message goes out, show the recipient, message, and attachments. Before a bulk update, show which records will change. Before a purchase, show the amount and payee.

For teams choosing an agent platform, I would prioritise a few controls over another polished demonstration:

• Task-scoped access: use short-lived access tokens with narrowly defined permissions, rather than broad access that remains active indefinitely.
• Separate preparation from execution: let the agent draft an action without necessarily authorising it to carry that action out.
• Enforce limits outside the model: apply tool-level permission checks even when the agent confidently requests an operation.
• Make consequential actions reviewable: require human approval for payments and other high-impact steps, with enough detail to support a real decision.
• Keep usable records: maintain agent action logs that connect tool calls, approvals, and outcomes, while protecting sensitive data in those records.

There are trade-offs. Tighter controls can interrupt workflows, and some low-risk actions are sensible to automate without repeated approval. The answer is not to put a confirmation box in front of everything. It is to match authority and oversight to the potential harm.

The best agent will not necessarily be the one that asks the fewest questions. It will be the one whose boundaries are clear enough that we can trust it to act inside them—and stop it when those boundaries need to change.