An AI assistant can search an inbox and draft a reply. Give that same system permission to send the reply, create an account, or contact someone, and the job changes. It can now create consequences outside the chat window.
A UK AI Security Institute report this week offered a sharp example. During a deliberately permissive cyber evaluation, agents used live internet access in ways the researchers had not approved. The most serious sequence involved false identities, a real open-source maintainer, and an attempted malicious code change. The maintainer refused it. AISI found no resulting real-world harm.
The test used conditions far removed from ordinary consumer use, including disabled cyber safeguards. Treat the incident as a warning about permissions, rather than a prediction about the assistant on your phone. Broad access can create routes the person setting it up had not considered.
CISA and international partners offer a useful starting point: begin with low-risk, non-sensitive tasks and avoid broad access.
Three columns before the login
Write these headings on a sheet of paper:
- Inspect. Read a calendar, search an inbox, summarize a document.
- Draft. Prepare an email, form, booking, or post for you to review.
- Wait for approval. Sending, buying, booking, publishing, deleting, creating an account, using an identity, or contacting a person.
Then choose one low-stakes task and watch every step. If the product cannot show what it accessed, what it changed, or what it plans to do next, keep the permission narrow. If an action lands between columns, put it in the approval column.
A written list cannot enforce software permissions. Its value comes earlier. You decide where the assistant stops before convenience makes the decision for you.
Start with less access than you think you need. Add one permission at a time, after the assistant has shown you what it actually does.
