An AI agent that can read documents, open email, query a database and click through a business application will finish some jobs faster than a person copying between tabs. The same reach is why security teams are uneasy. The agent is a new user of systems the business already has. If it can see sensitive files or take actions in several products, it is also a path an attacker, or a simple mistake, can use.
The model is not the whole system. The risk sits in what the agent is allowed to read, which tools it can call, whose identity it borrows, and whether anyone notices when it does something odd. A careful prompt is not a substitute for those controls.
What can go wrong when an agent acts
OWASP's 2026 risks for agentic applications include goal hijacking, tool misuse and unexpected code execution. Goal hijacking can happen when an agent follows malicious instructions embedded in content it reads, such as a webpage or a document. The user asked for a summary. The page asked the agent to do something else, and the agent treated that hidden text as part of the task. Tool misuse is the case where the agent uses a legitimate application in an unsafe way: sending, deleting, or changing a record because the task was read too broadly. Unexpected code execution is the case where the agent is persuaded to run something it should never have been able to run.
The OWASP GenAI Security Project walks through that 2026 list in its own briefing. The film covers the wider top 10, not only the three risks above. What it adds here is the reason those risks exist: an agent that calls tools is a different problem from a chatbot that only writes an answer.
OWASP's AI agent security cheat sheet is the practical companion to that list. Microsoft's writing on those risks in Copilot Studio shows how one vendor maps the same concerns onto a product. The pattern is not unique to one brand. Any agent that retrieves untrusted content and then calls tools has the same shape of problem.
A sentence in the prompt will not hold
Telling an agent "do not share confidential data" is not enforcement. The agent may still paste a customer record into a draft, call an external tool with the contents of a file, or follow a later instruction that contradicts the first one. Organisations should put the safeguard in the system. Limit each agent to the data and tools that one workflow needs. Keep testing separate from production. Require approval before a sensitive action. Log what the agent read and what it called.
Treat external documents, messages, webpages and API responses as untrusted input. That is the same habit developers already use for form fields, applied to material the agent fetches for itself. A staff handbook in an approved folder is not the same source as a webpage the agent found mid-task. Excessive permissions make every one of these failures worse, because a confused or compromised agent can reach systems the task never needed.
- One agent, one job, and a list of tools that job requires.
- No production data in a trial that is still being prompted by hand.
- Approval before send, pay, delete, publish or change a customer record.
- A log that shows the instruction, the tools and the result.
- External content treated as hostile until a person has accepted it.
Assess the workflow, then test the nasty cases
A business introducing agents should start with a risk assessment of the complete workflow. What information enters? Which tools can be called? Which identity does the agent use, and is that identity a shared super-user or a narrow account? What happens if the agent follows an incorrect instruction? Those questions belong to security, development and the people who own the process, together. A model card from the vendor does not answer them.
Testing should include realistic failures. A retrieved webpage that contains a hidden instruction. A tool response that asks the agent to take a second, broader action. A document that looks internal and is not. If the only test is a happy-path demo on clean data, the trial has not met the risks OWASP is naming. Governance of agentic AI is the management version of the same test: who may approve the action, and who reads the log. Google's Gemini agent is one product now offering that kind of multi-step work, with its own permission controls. The controls still have to be set.
Keep the agent from becoming a spare set of keys
With those limits, a firm can try automation without leaving an unmonitored route into mail, files and line-of-business systems. The agent should be less privileged than the person it helps, not more. When its tools or its job change, the review should change with them. A permission granted for a pilot in October is not automatically right in March.
UK GDPR applies where the content identifies someone. Logs of prompts and retrieved files can be personal data too. Knowing where they are stored is part of switching the agent on. Microsoft's 2026 defence report is a reminder that valid accounts and excess permissions are already a common way in. An agent identity is another account.
Build the boundary into the product
AI development that a UK firm can stand behind starts from the workflow and the permissions, not from a general assistant with every connector enabled. Software development is where those limits become something the system enforces, rather than a line in a prompt.
Web Works Rise is a UK-led team in Birmingham, with a development hub in Tunisia for delivery. If you are about to let an agent read company files or call a business tool, talk to the team about the smallest version of that job and the checks in front of any action that leaves the building.