CyphrQ
Menu

AI Agent Security Risks at Work: The Guardrails That Matter

What an AI agent is, why letting AI act brings new security risks, and the guardrails, vendor questions and 10-point checklist a manager needs.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

An AI agent is an AI tool that can act, not just answer: browse the web, read your inbox, use other apps and complete tasks on its own. The new AI agent security risks come from that ability to act. The guardrails are mostly old ones applied well: least privilege (only the access the job needs), a human sign-off before anything irreversible, one identity per agent, logs you can read, and a switch that stops it.

What is an AI agent, and how is it different from a chatbot?

A chatbot takes your question and gives you text. You decide what to do with it. If the answer is wrong, you catch it before anything happens.

An agent is given a goal and the means to pursue it. Depending on the product, it can open web pages, read and send email, edit files in shared drives, query databases, fill in forms, run code and call other software through "tools" or "connectors". It works in a loop: look at the situation, pick the next step, do it, look again.

That loop is the point. It is also the risk. Every step the agent takes without you is a step you did not check.

What are the new AI agent security risks?

These are the risks worth briefing a management team on, in general terms. Defences follow in the next section.

Excessive permissions. Agents are often connected with the full access of whoever set them up. OWASP's Top 10 for LLM Applications 2025 names this Excessive Agency (LLM06:2025) and defines it in one sentence: "Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction."

OWASP breaks the root cause into three parts: excessive functionality, excessive permissions and excessive autonomy. An agent that only needs to read a calendar should not be able to delete files.

Acting on untrusted content. An agent reads web pages, emails and documents written by strangers, and instructions hidden in them can turn into actions: that is prompt injection, which OWASP ranks first (LLM01:2025). How it works and how to defend against it is in Prompt Injection Explained.

Runaway loops and cost. An agent that keeps retrying, or that calls a paid service in a loop, can burn through money or API quotas quickly. OWASP lists Unbounded Consumption (LLM10:2025) for exactly this.

Data moving between tools. An agent that reads a confidential file and then drafts an email has, in effect, carried that data from one system to another. Nobody pasted anything. Anthropic's agent framework flags this as a privacy concern: agents that retain information should not carry sensitive data between unrelated contexts.

Shared agents under one identity. When five people use one agent that logs in as "automation@company", every action looks the same in your systems. You cannot tell who asked for what, and the agent carries the combined access of everyone who uses it.

Audit gaps. Many agent products show you the final result but not the steps. If the agent was tricked or simply wrong, you may have no trail to reconstruct what happened.

What guardrails actually reduce AI agent risk?

These are controls IT teams already understand. OWASP's mitigations for Excessive Agency map closely to the list below.

Risk Guardrail Source
Excessive permissions Least privilege and scoped credentials OWASP LLM06:2025 Excessive Agency
Acting on untrusted content Authorisation enforced in the systems, not in the AI OWASP LLM01:2025 Prompt Injection; NCSC on prompt injection
Runaway loops and cost A kill switch, with budget caps and rate limits OWASP LLM10:2025 Unbounded Consumption
Data moving between tools Human approval before irreversible actions, including external send and share Anthropic agent framework; OWASP LLM06:2025
Shared agents under one identity One identity per agent OWASP LLM06:2025 (user-scoped, least-privilege authentication)
Audit gaps Logging you can actually read OWASP LLM06:2025 (logging and monitoring)

Least privilege and scoped credentials

Give the agent the minimum set of tools, and give each tool the minimum access: read-only where read-only will do, one mailbox rather than the whole company's email, one folder rather than the whole drive. OWASP's guidance is to execute actions "in the context of the user" with least-privilege, user-scoped authentication, and to prefer narrow, specific tools over open-ended ones that can run arbitrary commands.

Human approval before irreversible actions

Sending, paying, deleting, publishing and sharing externally should pause for a person. It is also the first defence against prompt injection, as I set out in Prompt Injection Explained. Anthropic's framework puts it as a principle: "humans should retain control over how their goals are pursued," with approval before high-stakes decisions. Most agent products have an "ask before acting" setting. Find it and turn it on.

One identity per agent

Give each agent its own account, with its own credentials and its own permissions, rather than borrowing a person's login or sharing one service account across the team. That makes it possible to see what the agent did, to revoke its access in one move, and to keep its reach narrow.

Logging you can actually read

Log the agent's inputs, the tools it called and what it sent. OWASP notes that logging and monitoring will not prevent excessive agency, but they limit the damage and let you find out what happened. Decide in advance who looks at the logs and how often.

A kill switch

Someone needs the ability to stop an agent immediately: revoke its credentials, disable its connectors, or pause the service. Test that this works before you need it. Budget caps and rate limits on any paid service it uses belong in the same category.

Authorisation in the systems, not in the AI

Do not rely on telling the model "never delete files". Enforce that in the file system, the email platform and the database. OWASP's advice is to enforce authorisation in downstream systems rather than in the LLM. The UK NCSC made the same point in Prompt injection is not SQL injection (it may be worse): constrain the actions with ordinary, deterministic software.

How does this fit a wider AI governance approach?

If your organisation wants a framework rather than a list of controls, the NIST AI Risk Management Framework 1.0 (January 2023) organises the work into four functions: Govern, Map, Measure and Manage. NIST added a Generative AI Profile (NIST AI 600-1, July 2024) with actions specific to generative systems. NIST notes the framework is being revised, so check the current version.

For a manager, the useful part is the order. Decide who owns AI risk (Govern), list where agents are used and what they touch (Map), check what they actually do (Measure), and fix the gaps (Manage). The guardrails above are the Manage step.

What should you ask an AI agent vendor?

Seven questions for any AI agent vendor. Ask them before you connect anything to real data, and write the answers down.

  1. Which actions can the agent take without a human confirming, and can we switch each one off?
  2. Can we scope its access per user, per mailbox and per folder, rather than all or nothing?
  3. Does each agent get its own identity, or does it act as the user who set it up?
  4. How does it treat content from web pages, emails and files differently from our instructions?
  5. What is logged, where can we see it, and how long is it kept?
  6. How do we stop it instantly, and how do we cap what it can spend?
  7. Which OWASP or NIST guidance did you test against, and will you share the results?

If the answer to most of these is "the model is trained to behave", ask what happens when the training fails.

Going deeper: for security and IT teams

Map risks to agent-specific IDs. OWASP's Top 10 for Agentic Applications (December 2025) adds identifiers the LLM list lacks. The controls below target ASI02 Tool Misuse, ASI03 Identity & Privilege Abuse, ASI05 Unexpected Code Execution, ASI08 Cascading Failures and ASI10 Rogue Agents. LLM06 and LLM10 still cover the model layer. Goal hijack through injected content (ASI01) and its defences are in the prompt injection post.

Identity: pick the pattern on purpose. Treat each agent as a non-human identity with a named owner, a purpose and a review date.

Pattern How it acts Fits Ceiling
Delegated With a token issued for the signed-in user Personal assistants Reaches whatever that user can reach
Service identity As its own principal with its own grants Shared or scheduled agents Grants drift unless reviewed

Either way, request the narrowest OAuth scopes the task needs, prefer short-lived tokens, and review consent grants like any third-party app. Never share one principal across agents: you lose attribution and can't revoke one without breaking the others.

Tool access through MCP. Many agents reach tools via the Model Context Protocol. The MCP authorization spec (2025-06-18 revision) makes authorization optional. When an HTTP server uses it, the server acts as an OAuth 2.1 resource server and must publish Protected Resource Metadata (RFC 9728). Clients must send the RFC 8707 resource parameter, servers must reject tokens not issued for them, and a server "MUST NOT pass through the token it received from the MCP client." Local STDIO servers take credentials from the environment instead, so they inherit whatever secrets sit there. Keep a per-agent allowlist of approved servers and tools, and deny everything else.

Execution and egress. Run code-executing agents in an ephemeral sandbox with no standing credentials and read-only mounts. Send outbound traffic through an egress proxy with an allowlist.

In practice: in EchoLeak (CVE-2025-32711, CVSS 9.3), the case study reports that data left through a Microsoft Teams proxy that Copilot's content security policy already permitted. A list of trusted vendor domains wasn't enough, because one of them would forward requests. OWASP uses EchoLeak as its ASI01 example.

Change control for capabilities. In practice: on 14 August 2024, Slack AI began drawing on files from channels and DMs. PromptArmor's write-up says this widened the attack surface so that an attacker "may not even have to be in Slack", and it advised admins to restrict Slack AI's file ingestion. Treat a vendor update that changes what an agent reads or does as a permission change: review it and re-approve it.

Approval enforced in the tool layer. Have the tool endpoint refuse irreversible actions unless the request carries an approval from a human session. An instruction in the prompt is not a control.

Detection and audit. Log every tool call with the agent identity, the delegating user, the tool, its arguments, the result size and the destination, and send it to your SIEM. Alert on:

  • an agent using a tool for the first time
  • egress to a domain the agent hasn't contacted before
  • spikes in calls or tokens (LLM10)
  • repeated authorization failures, such as MCP servers returning 403 for insufficient scope

Test the kill switch on a schedule. Revoke the principal, then confirm its calls fail.

Ask your own team: can we list every agent identity and its grants today? Which MCP servers run without authorization? Where, exactly, is approval enforced?

Key takeaways

  • An agent differs from a chatbot in one way that matters for security: it can act without you watching each step.
  • The new risks are the old ones with the human removed: too much access, trusting the wrong content, no audit trail, no cost limit.
  • OWASP's Excessive Agency entry gives the fix in one line: limit functionality, permissions and autonomy.
  • Human approval before send, pay, delete and share is the single most valuable control.
  • Enforce limits in your systems, not in the prompt.

Checklist: 10 points before an agent touches real data

  1. The agent has a written purpose and a named owner.
  2. It has its own account and credentials, not a person's login.
  3. Its tools and connectors are the minimum for that purpose.
  4. Access is read-only wherever write access is not required.
  5. Send, pay, delete, publish and external share require a human to confirm.
  6. It cannot reach sensitive internal data and the open web or outside email in the same session, unless there is a specific reason.
  7. Logs of inputs, tool calls and outputs are on, and someone reviews them.
  8. There is a tested way to stop it immediately and revoke its access.
  9. Spending and rate limits are set on every paid service it uses.
  10. The vendor has answered the seven questions above in writing.

Sources