---
title: "Agentic AI security: the real risks for business | &above"
canonical_url: "https://www.andabove.com/feed/agentic-ai-security-risks"
last_updated: "2026-11-01T19:29:26.948Z"
meta:
  description: "Agentic AI security in practice: the five risks that bite when AI agents act inside real systems, and the controls a production team builds in before launch."
  "og:description": "Agentic AI security in practice: the five risks that bite when AI agents act inside real systems, and the controls a production team builds in before launch."
  "og:title": "Agentic AI security: the real risks for business"
  "twitter:description": "Agentic AI security in practice: the five risks that bite when AI agents act inside real systems, and the controls a production team builds in before launch."
  "twitter:title": "Agentic AI security: the real risks for business"
---

# &above

[&above](https://www.andabove.com/index.md)
[Work](https://www.andabove.com/work.md)
[Services](https://www.andabove.com/services.md)
[Agent Mesh](https://www.andabove.com/agent-mesh.md)
[Feed](https://www.andabove.com/feed.md)
[About](https://www.andabove.com/about.md)
[Contact](https://www.andabove.com/contact.md)

---


# Agentic AI security: the real risks of putting AI agents to work in your business

`AI`

*26 Oct 2026*

![Agentic AI security: the real risks of putting AI agents to work in your business](https://www.andabove.com/content-media/press/press-particle-6.gen.webp)

Agentic AI security is the work of making sure an AI agent can only do what it should, with the data it should, and that someone can see and undo what it did. It matters more than chatbot security because an agent does not stop at an answer. It updates the CRM, raises the refund, or edits the record.

This guide is for CTOs, heads of product and risk owners who want AI agents working inside real systems and are stuck on whether that is safe. It names the five agentic AI risks that cause real trouble, then sets out the guardrails a production team builds in before launch: narrow identities, approval steps on irreversible actions, logging, and an owner who runs the agent after launch. For the narrower question of whose identity an agent should act under, read [Native agent identity isn't the finish line](https://www.andabove.com/feed/native-agent-identity-isnt-the-finish-line.md). This piece covers the wider set of controls.

## What makes agentic AI a different security problem from chatbots

A chatbot answers. An agent acts. It can read from and write to your systems, chain several steps together, and finish a task on your behalf. That changes the security question. With a chatbot, the worst case is usually a wrong answer that a person reads before they do anything with it. With an agent, the output is the action. If the agent misreads an instruction, the mistake lands in a system of record before anyone sees it.

The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) names this risk [Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/): the vulnerability that lets an LLM-based system take damaging actions in response to unexpected, ambiguous or manipulated output, whatever made the model go wrong. OWASP traces it to three root causes: excessive functionality, excessive permissions and excessive autonomy. Each of those is a design decision, so each can be designed out.

Recorded Future's research on the [emerging enterprise security risks of AI](https://www.recordedfuture.com/research/emerging-enterprise-security-risks-of-ai) adds the integration angle. It notes that agents often require broad, cross-environment permissions, and that many AI tools that connect to external data or other tools currently operate in a trust-by-default mode. An agent wired into the CRM, the finance system and the shared drive inherits every weakness in how those connections were set up.

## The five agentic AI risks that actually bite

Several of these risks need no attacker at all. Zenity notes that agents repeating API calls, changing records on flawed assumptions or acting without re-checking their goal need no malicious input to do it. Many of the gaps start as shortcuts taken to get a demo working that then survive into production. These are the five to design for.

### 1. Over-broad permissions

The quickest way to get an agent working is to give it the access of the person who set it up, or a service account with standing access to a whole system. The agent then holds far more power than its task needs. OWASP's guidance is to limit the tools an agent can call, the functions inside those tools, and the permissions behind them to the minimum necessary. Zenity's guide to the [risks of agentic AI](https://zenity.io/academy/risks-of-agentic-ai) describes the subtler version: agents 'don't need to break access controls; they operate within them.' The damage comes from valid permissions used in ways nobody intended.

### 2. Prompt injection through the data agents read

Agents read emails, tickets, web pages, documents and CRM notes, and any of that text can contain instructions. OWASP calls this [indirect prompt injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). It occurs when a model accepts input from external sources, such as websites or files, and that content changes the model's behaviour in ways nobody intended. A support agent that reads an inbound email can be told, by the email, to do something its owner never asked for. Recorded Future's assessment is that completely securing agents against prompt engineering 'is likely impossible'. The design goal is to limit what a manipulated agent can do, rather than to assume it will never be manipulated.

### 3. Acting on stale or wrong context

An agent acts on what it can see. If the price list it reads is last quarter's, or the customer record is half-merged, it will act on the wrong facts with the same confidence as the right ones. Zenity calls this context drift. Agents act on what they know, 'but what they know can become outdated', and the agent's behaviour can drift from the expected workflow without any alert. A person might pause because something looks off. An agent only pauses if you build that check in.

### 4. No audit trail

When an agent changes a record, you need to know which agent made which call, on whose behalf, with what input, and who approved it. Without that record, an incident becomes guesswork, and nobody can tell a one-off error from a pattern. The UK government's [Code of Practice for the Cyber Security of AI](https://www.gov.uk/government/publications/ai-cyber-security-code-of-practice/code-of-practice-for-the-cyber-security-of-ai) asks system operators to 'log system and user actions to support security compliance, incident investigations, and vulnerability remediation'.

### 5. No clear owner

This is the quietest of the five. An agent launches, the project team moves on, and the model, the data and the process keep changing underneath it. Nobody watches the logs, reviews the permissions, or decides what the agent should stop doing. We covered the general pattern in [Your AI pilot worked. Now who owns it?](https://www.andabove.com/feed/your-ai-pilot-worked-now-who-owns-it.md). For an agent with write access to real systems, an unowned agent is also a security problem.

## Is it safe to run agentic AI at enterprise scale?

Yes, when the agent is built for it. Agentic AI is safe to run at enterprise scale when each agent has a narrow identity with only the permissions its task needs, a person approves the actions that cannot be undone, every action is logged, and a named owner runs the agent after launch. Without those controls, scale multiplies the risk: more agents, more systems, and more actions that nobody reviews.

Safe does not mean the model never makes a mistake. It means a mistake is small, visible and reversible. Plan for the agent to be wrong sometimes, and to be manipulated sometimes, and design so that neither causes harm you cannot undo. In practice, that means these conditions hold before the agent goes live:

- The agent can reach only the systems and records its task needs.

- Your systems, not the model, decide whether an action is allowed. OWASP calls this complete mediation.

- Irreversible or high-impact actions wait for a person to approve them.

- Every action is logged in a form someone can search during an incident.

- The agent has been tested against the inputs it will meet in production, including hostile ones.

- A named person owns the agent, its logs and its permissions after launch.

Enterprise scale also means many agents, not one. Recorded Future expects enterprises to expand their identity and access management frameworks to treat AI agents as priority digital identities, with least-privilege enforcement, behavioural monitoring and dedicated audit controls. The practical version is to treat each agent as a new kind of user with its own access review, rather than as a feature inside someone else's account.

## How to connect an AI agent to your existing systems safely

To connect a custom AI agent to your company's existing systems safely, give it its own identity with the narrowest scopes its task needs, let your systems enforce those permissions rather than trusting the model, require a person to approve any action that cannot be undone, and log every call it makes. Start read-only, and add write access one action at a time as the logs show the agent behaving as intended.

### Give the agent a narrow identity

An agent that signs in as a person, or through a shared admin account, can do everything that account can do. Give it an identity of its own, or act strictly in the context of the user it is working for. OWASP recommends that actions taken on a user's behalf run on downstream systems in that user's context, with the minimum privileges necessary, using OAuth with the minimum scope required as its example. Whether that identity should be borrowed or native, and broad or task-specific, is the subject of [Native agent identity isn't the finish line](https://www.andabove.com/feed/native-agent-identity-isnt-the-finish-line.md).

### Scope access to the task, not the system

List the actions the agent needs, then grant those and nothing else. An agent that summarises open opportunities needs to read them. It does not need to delete accounts or export the whole CRM. Enforce the limits in the systems the agent calls, not in its prompt. A prompt that says 'never delete records' is a request. A token without delete rights is a control.

### Put approval steps on irreversible actions

Sort the agent's actions by what happens if they go wrong. Reading data and drafting a reply can usually run unattended. Sending money, deleting records, contacting customers or changing access should wait for a person. OWASP's guidance is to require a human to approve high-impact actions before they are taken. Recorded Future compares these checkpoints to the fraud controls a business already places on its human employees. The agent prepares the refund, and someone in finance approves it.

### Treat what the agent reads as untrusted

Keep the content an agent reads apart from the instructions it follows. OWASP's prompt injection guidance includes segregating and clearly marking untrusted external content, and running adversarial tests against the agent. Test with the inputs a hostile sender could put in an email, a ticket or a shared document, not only the clean examples from the demo.

### Log every action

For each action, record the identity used, the request, the context the agent retrieved, the tool it called and with what parameters, the result, and who approved it. OWASP notes that logging and monitoring will not prevent Excessive Agency, but they limit the damage by showing where undesirable actions are happening. The UK Code of Practice also asks system operators to analyse their logs to detect anomalies and unexpected behaviour over time. Logs only help if someone reads them, and that is the owner's job.

## Agentic AI governance that doesn't kill speed

Agentic AI governance slows teams down when every change needs a committee. It keeps pace when a few rules are set once, built into the system, and owned by one named person who can change them.

That owner runs the agent after launch. They watch the logs, review the permissions, decide when the agent earns more autonomy and when it loses some, and retire it when the workflow changes. They are also the person who notices when a model update or a new data source changes how the agent behaves. The UK Code of Practice's principle on human responsibility for AI systems asks developers and system operators to build in the capability for human oversight. The owner is the person who uses it.

Autonomy can then grow on evidence rather than optimism. An agent might start by drafting every action for approval. Once the logs show a class of action is reliable, the owner can let that class run unattended and keep approval on the rest. That is faster than a launch that tries to settle every risk in advance, and safer than one that settles none.

Ownership is the step most pilots skip. [Your AI pilot worked. Now who owns it?](https://www.andabove.com/feed/your-ai-pilot-worked-now-who-owns-it.md) covers why, and [Scaling AI proof-of-concepts into production](https://www.andabove.com/feed/scaling-ai-prototypes-into-production.md) covers what else has to change between a working pilot and a system the business runs.

## A pre-launch checklist for agentic AI

Before an agent touches a real system, check that you can answer yes to each of these:

- The agent has its own identity, or acts strictly in the context of the user it works for.

- Its permissions list only the actions its task needs, and the target systems enforce them.

- Every action that moves money, deletes data, contacts a customer or changes access waits for a person to approve it.

- Content the agent reads from emails, documents, tickets and web pages is treated as untrusted input.

- The agent has been tested against hostile inputs as well as the happy path.

- The data it relies on has a known source and a known refresh schedule.

- Every call it makes is logged with the identity, input, action, result and approver.

- Someone can switch the agent off, and roll back what it did, without waiting for a release.

- A named owner watches the logs and reviews the permissions on a fixed schedule.

- You know who decides when the agent gets more autonomy, and on what evidence.

## How &above builds agents with these controls from day one

Who can build agentic AI workflows for an enterprise? A team that can design the agent, write the integration code against your systems, and build the permissions, approval steps and logging in the same pass, then stay long enough for your people to own the result. That can be an in-house team with senior AI engineers, or a partner whose engineers work inside your team. Be wary of a supplier who scopes the agent but hands the integration and the guardrails back to you. [How to choose an AI agent development company](https://www.andabove.com/feed/how-to-choose-an-ai-agent-development-company.md) sets out the questions to ask.

This is how we work. Permissions, business-logic guardrails and observability go into every agent system we ship, from the first build rather than after a proof of concept. Our [forward-deployed engineers](https://www.andabove.com/services/forward-deployed-engineers.md) are senior AI engineers whom &above hires and manages. They work inside your team, in your repositories and your tools, so the people building the controls are the people who know your systems. Because they build alongside your people, your team owns the system and can extend it after the engagement ends.

The [Gemini Sales Sidekick we built for Google Cloud](https://www.andabove.com/work/google/scaling-googles-salesforce-with-custom-solutions.md) connects Cloud's Sales Hub, Salesforce and intranet behind single sign-on, and is used by 5,000 sellers. For [Tesco Retail Media](https://www.andabove.com/work/tesco/retail-media-from-weeks-to-live-in-days.md), the team built an evaluation suite to test Gemini against real approval rules before the AI became part of the approval process.

[AI agent development](https://www.andabove.com/services/ai-agent-development.md) sets out how we scope, connect and run agents for scale-ups and enterprises.

## Frequently asked questions

### What are AI agent guardrails?

AI agent guardrails are the limits that keep an agent inside its job: narrow permissions, rules the target systems enforce, human approval on high-impact actions, checks on the content the agent reads, and logging of what it did. The guardrails that matter most sit outside the model, in the systems it calls. A manipulated prompt can change what the agent tries to do, but a permission check in the target system still decides what it can do.

### Can prompt injection be prevented completely?

No current technique prevents it completely. OWASP says it is unclear whether fool-proof prevention methods exist and lists measures that reduce the impact instead. Recorded Future's assessment is that completely securing agents against prompt engineering is likely impossible. The practical answer is to assume an agent can be manipulated and limit what a manipulated agent can do, through least privilege, approval on high-risk actions and monitoring.

### What is the OWASP Top 10 for LLM Applications?

It is a list of ten security risks for applications built on large language models, published by the OWASP Gen AI Security Project. The 2025 edition includes Prompt Injection (LLM01) and Excessive Agency (LLM06), the two entries most relevant to agents that take actions in other systems.

If you want agents working in your systems with these controls built in from the start, [get in touch](https://www.andabove.com/contact.md).


## Next up

- [Your AI rollout needs better behaviour design](https://www.andabove.com/feed/your-ai-rollout-needs-better-behaviour-design.md)
- [Your AI is only as good as the knowledge it can retrieve](https://www.andabove.com/feed/your-ai-is-only-as-good-as-the-knowledge-it-can-retrieve.md)
- [View our feed](https://www.andabove.com/feed.md)


---

## Footer

### Pages

- [Home](https://www.andabove.com/index.md)
- [Work](https://www.andabove.com/work.md)
- [Services](https://www.andabove.com/services.md)

### Studio

- [About](https://www.andabove.com/about.md)
- [Careers](https://www.andabove.com/careers.md)
- [Feed](https://www.andabove.com/feed.md)
- [Press kit](https://www.andabove.com/brand.md)

### Legal

- [Privacy](https://www.andabove.com/privacy-policy.md)
- [T&C](https://www.andabove.com/terms.md)

### Our partners

- Anthropic
- Google Cloud Partner
- Vercel
- Webflow Certified Partner

### Recognition

- [Top Clutch.co Artificial Intelligence Company England 2026](https://clutch.co/profile/above-1?utm_source=clutch_top_company_badge&utm_medium=image_embed&badge=127900)

### Contact

[Contact](https://www.andabove.com/contact.md)

1st Floor, The Binary,
27 Copperfield St
London, SE1 0EN

© 2026 &above™