Are AI agents safe? Prompt injection, permissions and approval settings

Published by 3Gen Internet Corporation, maker of OpenAssistant, Skej and AGNT. Comparisons use public documentation, without hands-on testing.

AI agents carry real risks, and the primary sources say so plainly: the UK National Cyber Security Centre writes that prompt injection attacks may never be totally mitigated. Controls reduce the risk. The ones that matter most are narrow permissions, approval before consequential actions, and a way to stop everything fast. OpenAssistant is used below as one worked example of those controls, using what its own pages state.

What can go wrong

An agent reads content (emails, web pages, documents) and then takes actions with real accounts. That combination is where the risk sits. The sources below are the ones security teams cite.

OWASP Top 10 for LLM applications (2025 list)

OWASP’s Gen AI Security Project lists ten risks for LLM and generative AI apps (OWASP LLM Top 10): LLM01:2025 Prompt Injection; LLM02:2025 Sensitive Information Disclosure; LLM03:2025 Supply Chain; LLM04:2025 Data and Model Poisoning; LLM05:2025 Improper Output Handling; LLM06:2025 Excessive Agency; LLM07:2025 System Prompt Leakage; LLM08:2025 Vector and Embedding Weaknesses; LLM09:2025 Misinformation; LLM10:2025 Unbounded Consumption. The site page is labelled “LLMRisks Archive” and shows no newer LLM edition.

Two items matter most for agents:

• LLM01 Prompt Injection. OWASP says indirect prompt injections happen when a model accepts input from external sources, and that it is unclear whether fool-proof prevention exists (OWASP LLM01).
• LLM06 Excessive Agency. OWASP names the root causes as excessive functionality, excessive permissions and excessive autonomy. Its mitigations include requiring a human to approve high-impact actions. Its example scenario is an assistant with mailbox read access and send functions that forwards inbox content to an attacker after an injected email (OWASP LLM06).

OWASP Top 10 for Agentic Applications (2026)

A separate OWASP list covers agents specifically: “OWASP Top 10 for Agentic Applications for 2026”, dated 9 December 2025 on the resource page. Its items are ASI01 Agent Goal Hijack; ASI02 Tool Misuse and Exploitation; ASI03 Identity and Privilege Abuse; ASI04 Agentic Supply Chain Vulnerabilities; ASI05 Unexpected Code Execution (RCE); ASI06 Memory & Context Poisoning; ASI07 Insecure Inter-Agent Communication; ASI08 Cascading Failures; ASI09 Human-Agent Trust Exploitation; ASI10 Rogue Agents (OWASP agentic list). The document says agents and the underlying model cannot reliably distinguish instructions from related content, and one of its mitigation headings is “Least Agency and Least Privilege for Tools”. The two lists use different numbering (LLM01 versus ASI01), so cite each with its own prefix.

NIST and the UK NCSC

• NIST’s CAISI technical blog, dated 17 January 2025, treats agent hijacking as indirect prompt injection and states that many AI agents are vulnerable to it. It added injection tasks for remote code execution, database exfiltration and automated phishing (NIST CAISI blog).
• The NCSC blog “Prompt injection is not SQL injection (it may be worse)”, published 8 December 2025, says prompt injection attacks will remain a residual risk and advises focusing on deterministic (non-LLM) safeguards that constrain what the system can do (NCSC).

What vendors say about their own agents

Vendors do not claim the problem is solved. Their statements, as recorded:

Anthropic also publishes attack-success figures: about 1% for the Claude Opus 4.5 browser extension against an internal adaptive attacker (November 2025 post), and less than 0.08% for Claude Opus 4.8 with its current configuration (help article). These are vendor claims from internal evaluations on different models and setups, so they are not comparable with each other, and they are not independent measurements.

The controls to look for

The same sources point to the same short list. Ask any vendor which of these it offers and where it documents them.

1. Least-privilege access. Give the agent only the accounts, folders and tools the job needs. OWASP lists excessive permissions and excessive functionality as root causes of excessive agency. Anthropic’s computer-use documentation recommends a dedicated virtual machine or container with minimal privileges (Anthropic computer-use docs). The NCSC advice is to constrain actions with deterministic safeguards, not rely on the model to behave.
2. Approval before consequential actions. OpenAI’s agent-building guide rates each tool as low, medium or high risk using read-only versus write access, reversibility, permissions and financial impact, and names high-risk actions such as authorizing large refunds or making payments as triggers for human intervention (OpenAI practical guide). OWASP LLM06 says to require a human to approve high-impact actions.
3. Confirmation windows versus hard approval. These are different. A window lets an action go ahead if you do nothing. Hard approval blocks it until you say yes. Check which one a product uses for sending messages, spending money and deleting data.
4. An account-wide stop. One control that halts everything pending or in flight, and that the agent cannot undo.
5. Admin lock. For teams, a way for an administrator to set limits that users and the agent cannot loosen.
6. Audit logs. A record of who did what and when, exportable for review.
7. Separate identity. The agent acts under its own name, email address and number, so its actions are distinguishable from yours, and what it can do as you is a separate switch.

OpenAssistant as one example

OpenAssistant is an AI assistant that works through email, text, phone calls and Slack, with its own identity. Here is how its published pages map to the list above (all). We have not verified any of this in use; these are the vendor’s statements.

• Autonomy levels, per action. The help center describes three levels: Manual (the assistant will not act until you explicitly approve), Confirmation Window (you get a configurable period to approve, modify or cancel, and “the assistant proceeds automatically” if you do nothing) and Autonomous (it acts immediately). Autonomy can be set globally or for specific action types: email from the assistant, email sent as you, messages from the assistant in Slack, Teams, SMS and WhatsApp, calendar actions, file actions, contact actions and third-party skills (OpenAssistant autonomy settings).
• A window is not hard approval. The vendor says so itself: a Confirmation Window is not the same as Manual approval, so use Manual if an action must always wait for you. It suggests starting with more oversight and adjusting as you become comfortable (choosing your settings). A changelog entry dated 20 October says that even on tasks set to act on their own, email from your account, your own Slack or Teams messages, or a call in your voice ask first unless you chose otherwise (changelog).
• Consequential actions staged for review. The Trust Center says consequential actions are staged for your review and shown in full before they are sent, and that for messages no AI model runs between your approval and the send, so the words you approved are the words that go out (Trust Center).
• No loosening its own oversight. The same page says the assistant cannot loosen its own oversight: tightening is allowed, loosening is blocked.
• Account-wide stop. The Trust Center describes an account-wide stop that halts every pending and in-flight action and is released only from your own account.
• Admin lock. Per the product page, an admin can lock autonomy settings for everyone (OpenAssistant executive assistant page). The Trust Center adds that admins control which third-party tools people may connect, can allow-list or block skills, and can enable or disable MCP tool connections org-wide.
• Narrow permissions. The connections article says calendar read and write permissions are required for scheduling, contacts are strongly recommended and inbox access is optional. The integrations article says connections do not automatically give the assistant unrestricted access to a service (connections overview). The data policy says inbox access is optional and only available when explicitly authorized (AI usage and data policy).
• Audit logs. The Trust Center mentions exportable audit logs of administrative activity alongside SAML SSO and SCIM. The pricing page lists “Audit logs & data retention” under Enterprise (pricing page text).
• Separate identity. The assistant has its own name, email inbox, phone number, calendar and sandboxed computer, and the vendor says it never pretends to be you unless you tell it to. Sending as the assistant and sending as you are separate autonomy categories.
• Security and data statements. The Trust Center states SOC 2 Type II, audited annually by an independent CPA firm, with the report available on request from security@openassistant.us. It also states: “We never train on your data.” These are vendor statements; we have not seen the audit report.
• What is not stated. The OpenAssistant pages recorded for this article do not discuss prompt injection by name, and they publish no attack-success figures. Ask the vendor directly. The vendor’s pages also note that Autonomous means no review before action, so the protection depends on the levels you pick.

OpenAssistant is a general work assistant, not a specialist security product, and it makes no promise that prompt injection cannot happen. If you want to look at these settings yourself, open OpenAssistant and begin at Manual.

For the wider buying questions, see how to choose an AI agent. For agents that contact other people, see AI agents that send emails, make calls and text.

Rules that touch agents acting for you

Two public rules come up when an agent speaks to other people. We record their wording and status only. This is not legal advice.

FCC ruling on AI voices (United States). FCC Declaratory Ruling FCC 24-17 (CG Docket No. 23-362) was adopted 2 February 2024 and released 8 February 2024. The ruling text says it encompasses current AI technologies that generate human voices, lists voice cloning among them, and says calls using such technologies fall under the TCPA and need the called party’s prior express consent unless an emergency purpose or exemption applies (FCC 24-17). Whether it applies to a specific product or call was not assessed.

EU AI Act, Article 50 (transparency). Regulation (EU) 2024/1689, dated 13 June 2024, requires in Article 50(1) that providers design AI systems meant to interact directly with people so that those people are informed they are dealing with an AI system, unless this is obvious from the point of view of a natural person. Article 50(2) requires providers of systems that generate synthetic audio, image, video or text to mark outputs in a machine-readable format. The original Article 113 says the Regulation applies from 2 August 2026 (EUR-Lex, Regulation 2024/1689). Regulation (EU) 2026/1744 of 8 July 2026 (the “Digital Omnibus on AI”) adds a transition: providers of systems that generate synthetic audio, image, video or text and were placed on the market before 2 August 2026 must take the necessary steps to comply with Article 50(2) by 2 December 2026 (EUR-Lex, Regulation 2026/1744). A Future of Life Institute site (not an official EU source) says the amending act entered into force on 27 July 2026 (artificialintelligenceact.eu). The full amended Article 113 was not read, and Article 50(1) is not shown as changed in the amending text read via the artificialintelligenceact.eu copy. Check the current text before relying on any date.

This is not legal advice.

Pre-flight checklist: 10 questions before an agent touches real accounts

1. Which accounts, files and tools can it reach, and can I narrow that to the job?
2. Which actions need my approval every time, and is that a hard approval or a window that proceeds if I do nothing?
3. Can it send messages, spend money or delete data without asking? Can I turn that off per action type?
4. Does it act as itself or as me, and are those separate settings?
5. Is there an account-wide stop, and who can release it?
6. Can an administrator lock settings so users and the agent cannot loosen them?
7. Is there an audit log, and can I export it?
8. What does the vendor say about prompt injection, and does it give a figure or only a general statement?
9. What does the vendor say about training on my data, and where is that written?
10. Where does it not work or not apply (outside contacts, group chats, certain countries), and what happens then?

Related reading

• How to choose an AI agent: 10 questions to ask before you buy: Ten questions on job fit, channels, approvals, price, data and exit, with a job-to-product table.
• What is an AI agent? Definition, types and examples: Four vendor definitions side by side, seven types with examples and a six-question test.
• Best AI browser and computer-use agents in 2026, compared: Nine browser and computer-use agents compared on documented controls, where the browser runs, approvals and prices.
• Best AI agents that send emails, make calls and text for you in 2026: Six picks for agents that send emails, make calls and text, ranked on prices, approval controls and consent rules.
• Best enterprise AI agents in 2026: governance, pricing and platforms: Enterprise agent platforms compared on governance, audit logs and price.

Frequently asked questions

Are AI agents safe to use at work?

They can be used with care, but they are not risk-free. NIST says many agents are vulnerable to hijacking, the NCSC says prompt injection will remain a residual risk, and OWASP names excessive permissions and autonomy as root causes of excessive agency. Start with narrow access, require approval for consequential actions and review what the agent did.

What is prompt injection?

It is an attack where instructions hidden in content an agent reads, such as an email or web page, try to steer what the agent does. OWASP lists it as LLM01:2025, and the agentic list’s ASI01 Agent Goal Hijack covers the related goal-redirection risk.

Does human approval remove the risk?

It reduces it. Microsoft says it relies on explicit user consent where other defenses cannot fully mitigate a risk, OpenAI says explicit confirmation further reduces the risk, and OWASP recommends human approval for high-impact actions. A confirmation window that proceeds if you do nothing gives weaker protection than approval that waits for you.

Can I stop an agent that is doing something wrong?

Look for a documented account-wide stop and an admin lock before you grant access. OpenAssistant’s Trust Center describes the stop, and its product page describes the admin lock. Ask any other vendor the same question.

Try OpenAssistant

If you want an assistant that acts across email, text, calls and Slack with per-action approval settings, you can try OpenAssistant. Start at Manual approval, review what it stages, and loosen settings only as trust builds.