UNTRUSTED TEXT SHOULD NOT BECOME AN ORDER TO YOUR CONNECTED ACCOUNTS.
You ask an AI assistant to summarise a webpage. Hidden in that page is an instruction telling the assistant to search your connected drive, open a private file and send its contents elsewhere. The webpage is supposed to be information; the hidden sentence tries to become an order. That is the central danger of indirect prompt injection when an AI agent has access to real accounts and tools.
If you use an AI assistant only to answer questions, a manipulated answer may waste time or mislead you. If you connect email, cloud storage, calendars, payments or browser controls, the same manipulation could produce a real-world action. The OWASP GenAI Security Project treats prompt injection as a major application risk, while its excessive-agency guidance explains why overly broad tool permissions can amplify mistakes.
This article is for people who want to understand or limit that exposure. It is not a claim that every connected assistant is compromised, or a prediction that AI will take control. It explains the permissions and boundaries you can inspect if these developments concern you.
What is AI agent prompt injection?
A prompt is an instruction sent to an AI model. A direct prompt injection attempts to manipulate the system by communicating instructions to it directly. An indirect prompt injection instead hides instructions in material the agent is expected to read: a webpage, an email, a document, a calendar invite, a support ticket or the text returned by another tool.
Ordinary documents can contain instructions as part of their subject matter. That is not automatically malicious. The danger begins when the assistant treats text from a lower-trust source as if it had permission to redirect its behaviour, override your request or command a connected tool.
| Input the agent encounters | Legitimate task | Unwanted redirection |
|---|---|---|
| Supplier email | Summarise the requested delivery date | Send a separate email with private account details |
| Search-result webpage | Extract useful research | Change the agent's answer or trigger a tool call |
| Shared cloud document | Find a project deadline | Read unrelated files and disclose their contents |
| Calendar invitation | Check meeting details | Modify another event or contact list |
| Repository comment | Explain a code change | Run an unsafe command in a development environment |
The important question is not whether a sentence sounds persuasive. It is whether the software enforces a barrier between data to be examined and actions the user actually authorised.
Why connections make the same message more dangerous
Agents may have permissions to read files, search inboxes, edit documents, book appointments, move data and interact with websites. Some tool connections can work across several services in the same session. A malicious instruction inside one piece of content can try to exploit these capabilities and make the assistant perform a different task.
Imagine an assistant that can read an inbox and a cloud drive. You ask it to find the date on a travel confirmation. The message it reads contains an instruction to fetch an unrelated confidential file. If tool permissions and approvals are too broad, that untrusted text could influence a tool request. This is a risk scenario; it does not establish that your particular assistant behaves that way.
Google's December 2025 security work on agentic browsing identifies unwanted transactions and data exfiltration as risks from injected webpage content. Permission design matters at least as much as how polite or convincing an assistant seems.
What research had demonstrated by 2026
Researchers have found prompt-injection attacks in controlled experiments and publicly accessible content. Google's April 2026 sweep of the public web identified attempts ranging from tone manipulation to harmful commands. The researchers described limits in what their dataset captured; a scan of publicly archived pages cannot measure every attack in private documents, email or business tools.
Google Research's 2026 PI-Hunter work explores ways of uncovering vulnerable paths through which untrusted instructions influence an agent. These studies do not establish a single success rate for every product, but they make the underlying trust-boundary problem concrete.
There is a distinction between a malicious page attempting to issue an instruction and an agent successfully carrying it out. Successful exploitation depends on the assistant, its available tools, permissions, safeguards and whether a human must approve a consequential action. Treat reports of attempted attacks, lab results and confirmed real-world harm as different evidence categories.
Five things to inspect before connecting an account
- Exact access scope. Does the assistant need the entire inbox or just selected messages? Full-drive access or one chosen document? A narrow, task-specific connection is easier to control.
- Read versus write. Reading a schedule is different from changing it. A service that offers separate permissions should not receive edit rights for a reading-only task.
- Whether actions can run unattended. Look for approval prompts for messages, purchases, file deletions, sharing changes and payments. An approval should describe the real destination and exact action.
- Ability to revoke access. Find the connection-management page and understand whether revoking a tool also revokes the underlying token or authorisation.
- Visibility of actions. Can you review sent messages, recent sign-ins, file-sharing history or audit logs? A usable record helps you determine what happened after a suspicious event.
Do this review inside the account provider's own settings where available. Marketing descriptions such as 'secure by design' cannot substitute for knowing what the connection can actually do.
Set permissions by consequences, not convenience
A useful model is to classify actions into three groups. The exact groups will vary with your circumstances.
| Action type | Example | Reasonable control |
|---|---|---|
| Low-consequence read | Summarise a public article | Usually no personal account connection needed |
| Private-data read | Review a personal email or customer record | Limit the source and consider disclosure sensitivity |
| Change with consequences | Send email, share a private file, delete records, make a payment | Require clear, action-specific review and approval |
For a small business, an agent can have access to mundane research without needing payroll, administrator privileges or the ability to share confidential documents externally. Separate high-consequence workflows rather than using one all-powerful connection for everything.
OWASP recommends least privilege, independent enforcement of tool permissions and human review of high-risk operations. These controls need to be implemented by the application or service, not merely written as a polite instruction inside a conversation.
A practical connected-account audit
You can carry out a non-technical audit without attempting to attack the assistant. Make a list of each connected service, the data it can read, the actions it can perform and the permissions you remember granting. Then compare that list with your current needs.
- Open the provider's security or connected-app settings directly; do not use a link from an unexpected email.
- Record the names of AI applications with access to email, drive, calendar, messaging or financial data.
- Identify connections you no longer use and revoke those permissions.
- For needed integrations, check whether read-only, folder-limited or single-file access is available.
- Inspect sent-message history, sharing history and recent account sign-ins for anything you did not initiate.
- Review whether important actions display a confirmation screen before execution.
- Repeat the audit whenever the tool gains new features or requests additional permissions.
If a provider does not expose granular controls, decide whether the usefulness of that connection justifies the broader access. You may prefer manual copy-and-paste of a non-sensitive excerpt rather than granting an entire account to a tool.
Do not confuse a human approval popup with a security boundary
An approval window is valuable only if it shows the consequential action clearly and actually stops execution until you decide. A vague 'continue' button can conceal important context. Look for the recipient of an outgoing email, the destination of a shared file, the account affected, the amount of a transaction and any hidden attachments or extra actions.
If the assistant unexpectedly proposes sending a message, moving funds or changing permissions when you asked for a summary, decline the action and investigate where the instruction came from. Do not approve simply because the request appears in the assistant's normal interface.
Similarly, an assistant saying 'I will ignore malicious instructions' is a statement of intent, not proof that all indirect injections will fail. Genuine protection also requires external access controls, tool validation and testing.
What to do if an agent appears to have acted without permission
Stop the workflow and avoid giving further approvals. Review what the account provider says actually happened: sent messages, file access, permissions changed, account sessions, transaction history and shared links. Take screenshots or exports of relevant logs where practical, without spreading private data.
Revoke suspicious connected-app permissions through the legitimate account settings. If account takeover is possible, use a trusted device to secure your email and critical services, rotate compromised credentials and review recovery methods. For financial transactions, contact the financial provider immediately. Our data breach first-hour guide covers a broader response sequence.
Tell the tool provider what you observed and include the source document or page if you can share it safely. In a business setting, follow incident-response processes; an IT administrator may need to investigate token usage and determine whether confidential data was exposed.
Could prompt injection help a future AI evade human control?
Prompt injection is a specific problem in how current systems interpret untrusted inputs. Broader questions about whether future AI agents could retain access, coordinate complex actions or resist oversight involve additional capabilities and conditions. The existence of prompt injection does not, on its own, demonstrate an AI takeover; neither does fixing one vulnerability resolve the wider question of future AI control.
People concerned about more autonomous AI can focus on one measurable boundary today: what can an assistant do without fresh human authorisation, and how could that authority be withdrawn? This is a practical way to examine risk without making an unsupported prediction. Our AI loss-of-control briefing explores the wider distinctions.
A safe five-minute exercise
Choose an AI integration you already use. Without providing sensitive material or using a hostile prompt, ask yourself: What is the smallest task I need it to do? What information must it see? What would be the worst credible side effect if it acted on an instruction from an unexpected email or webpage? Where is the revoke-access control?
Write one sentence describing the acceptable permission boundary: for example, 'Summarise only the three documents I select; do not send, share, change or delete anything.' Then check whether the app's actual permissions and approval design enforce that boundary. If they do not, the sentence alone is insufficient.
Frequently asked questions
Is prompt injection the same as hacking my password?
No. Prompt injection tries to influence an AI system through instructions in text or other content. It may lead to data disclosure or unauthorised actions if the system has overly broad capabilities, but it does not necessarily involve stealing your password.
Can an email contain an instruction for an AI agent?
Yes. An agent reading an email may encounter text intended to redirect its behaviour. The danger depends on whether the assistant treats that content as untrusted data and what tools it can operate.
Does using only read-only connections remove the risk?
Read-only limits some kinds of damage but can still expose sensitive data if the assistant discloses what it reads. Choose narrowly scoped data access and review where outputs can be sent or shared.
Should I disconnect every AI tool?
That is a personal risk decision. The more useful question is whether each connection is necessary, appropriately restricted and revocable. You can reduce permissions or work with selected files instead of granting blanket access.