# AI Agents Are Becoming Your New Attack Surface: 7 Security Flaws Most SaaS Companies Aren’t Testing > AI agent security for SaaS: 7 untested flaws—prompt injection, excessive agency, cross-tenant leaks, MCP tool risks—with tests and fixes mapped to OWASP. Author: SaaS Security Research Team · Published: November 3, 2026 AI agents have moved from demos into production SaaS products. They answer support tickets, update CRM records, write code, trigger workflows and call internal APIs on a user’s behalf. Each of those capabilities is useful—and each one is an entry point an attacker can try to steer. Traditional application security testing was built for predictable code paths. An agent decides at runtime which tool to call, with which inputs, based partly on content it did not author. This guide explains the seven AI agent security flaws we see SaaS teams leave untested, how to test each one safely, and how to fix them. It is mapped to the [OWASP Top 10 for LLM Applications (2025)](https://genai.owasp.org/llm-top-10/) and reflects public guidance as of November 2026. ## Quick Answer: What Are The Biggest AI Agent Security Risks? **The seven AI agent security flaws most SaaS companies are not testing are: (1) indirect prompt injection through data the agent reads, (2) excessive agency from over-privileged tools, (3) broken authorization where the agent acts as a confused deputy across tenants, (4) insecure handling of agent output in downstream systems, (5) unvetted tools, plugins and MCP servers, (6) memory and retrieval poisoning with cross-tenant leakage, and (7) missing human approval, audit logs and usage limits.** The common thread: an AI agent combines untrusted input with real permissions. Because prompt injection cannot be fully prevented today, the goal of AI agent security is to limit what a manipulated agent can do and to detect it quickly when it happens. ## In This Guide - [Why AI agents change your attack surface](#why-agents) - [Flaw 1: Indirect Prompt Injection Through Data The Agent Reads](#indirect-prompt-injection) - [Flaw 2: Excessive Agency: Tools With More Power Than The Task Needs](#excessive-agency) - [Flaw 3: Broken Authorization: The Agent As A Confused Deputy](#confused-deputy) - [Flaw 4: Insecure Output Handling In Downstream Systems](#insecure-output-handling) - [Flaw 5: Unvetted Tools, Plugins And MCP Servers](#tool-supply-chain) - [Flaw 6: Memory And Retrieval Poisoning With Cross-Tenant Leakage](#memory-rag-leakage) - [Flaw 7: No Human Approval, Audit Trail Or Usage Limits](#missing-guardrails) - [A 5-step AI agent security test plan](#test-plan) - [Frequently asked questions](#faq) ## Why AI Agents Change Your SaaS Attack Surface A conventional web feature takes a defined input and runs defined code. An AI agent takes natural language, reasons over documents and tool results, and chooses actions. Security researchers describe the dangerous combination as three ingredients present at once: - **Access to private data**—customer records, files, internal knowledge bases. - **Exposure to untrusted content**—emails, tickets, uploads, web pages, third-party tool responses. - **The ability to act or communicate externally**—send messages, call APIs, render links, write records. When all three exist in one agent, an attacker who controls the content may be able to make the agent move data out or take actions. Your existing [API security testing](https://www.saassecurity.io/blog/api-security-testing) and [web application penetration testing](https://www.saassecurity.io/blog/web-application-penetration-testing) remain necessary, but they do not exercise this path on their own. ## The 7 AI Agent Security Flaws At A Glance AI agent security flaws mapped to OWASP Top 10 for LLM Applications (2025) | # | Flaw | OWASP mapping | | 1 | Indirect Prompt Injection Through Data The Agent Reads | OWASP LLM01: Prompt Injection | | 2 | Excessive Agency: Tools With More Power Than The Task Needs | OWASP LLM06: Excessive Agency | | 3 | Broken Authorization: The Agent As A Confused Deputy | OWASP LLM06 and API1: Broken Object Level Authorization | | 4 | Insecure Output Handling In Downstream Systems | OWASP LLM05: Improper Output Handling | | 5 | Unvetted Tools, Plugins And MCP Servers | OWASP LLM03: Supply Chain | | 6 | Memory And Retrieval Poisoning With Cross-Tenant Leakage | OWASP LLM08: Vector And Embedding Weaknesses; LLM02: Sensitive Information Disclosure | | 7 | No Human Approval, Audit Trail Or Usage Limits | OWASP LLM10: Unbounded Consumption | ## Flaw 1: Indirect Prompt Injection Through Data The Agent Reads **Maps to:** OWASP LLM01: Prompt Injection Most teams test what a user types into the chat box. Far fewer test what happens when the agent summarizes a customer email, a support ticket, a PDF, a web page or a tool response that contains hidden instructions. The model cannot reliably tell your system prompt apart from text an attacker planted in the data it was asked to read. ### Example Attack Scenario A support agent summarizes an inbound ticket. Hidden text in the ticket tells it to look up the latest invoices and include them in its reply. If the agent has read access to billing and can send email, the attacker receives data they were never authorized to see. (Illustrative scenario, not a specific incident.) ### How To Test It - Plant instructions in every content source the agent ingests: uploads, emails, tickets, CRM notes, web pages and retrieved documents. - Check whether the agent follows them, reveals its system prompt, or calls tools it was not asked to call. - Test hidden formats: white-on-white text, HTML comments, image alt text, document metadata and Markdown links. ### How To Fix It - Treat all retrieved content as untrusted data, and separate it clearly from instructions. - Limit what any single agent run can do so a successful injection has a small blast radius. - Block automatic rendering of model-generated links and images that can exfiltrate data through URLs. ## Flaw 2: Excessive Agency: Tools With More Power Than The Task Needs **Maps to:** OWASP LLM06: Excessive Agency Agents are often connected with a broad API key or an admin service account because it is the fastest way to make a demo work. The result is an agent that can delete, refund, export or email when its job only requires reading. OWASP describes this as excessive functionality, excessive permissions and excessive autonomy. ### Example Attack Scenario A “reporting assistant” is granted a database role with write privileges. A crafted prompt convinces it to run an update that changes every customer’s plan. (Illustrative scenario, not a specific incident.) ### How To Test It - Inventory every tool, the credential behind it and the actions it permits. - Try to make the agent perform destructive or financial actions outside its stated purpose. - Confirm read-only tools are genuinely read-only at the API or database layer, not just described that way in the prompt. ### How To Fix It - Give each tool the narrowest scope possible, ideally a dedicated read-only credential. - Split high-impact actions into separate tools that require explicit confirmation. - Remove tools the agent does not need; unused capability is pure risk. ## Flaw 3: Broken Authorization: The Agent As A Confused Deputy **Maps to:** OWASP LLM06 and API1: Broken Object Level Authorization When an agent calls internal APIs with its own service identity instead of the signed-in user’s identity, your normal tenant and role checks may never run. The agent becomes a “confused deputy”: a privileged component that does whatever the least-privileged requester asks. ### Example Attack Scenario A user in Tenant A asks the assistant, “Show the open tickets for account 4821.” Account 4821 belongs to Tenant B, but the agent queries with a service key that can see every tenant—and answers. (Illustrative scenario, not a specific incident.) ### How To Test It - Create two tenants and ask each tenant’s agent for the other’s records by ID, name and email. - Check whether tool calls carry the end user’s identity and whether the backend enforces it. - Attempt role escalation: ask a member-level user’s agent to perform admin-only actions. ### How To Fix It - Enforce authorization in the tool or API, never in the prompt. - Pass the end user’s identity and tenant to every tool call and validate it server-side. - Use row-level security or per-tenant credentials so the agent cannot see other tenants even if asked. ## Flaw 4: Insecure Output Handling In Downstream Systems **Maps to:** OWASP LLM05: Improper Output Handling Model output is attacker-influenced input. When an agent’s response is inserted into a web page, SQL query, shell command, template, spreadsheet or another API without validation, classic vulnerabilities return: cross-site scripting, SQL injection, command injection and server-side request forgery. ### Example Attack Scenario An agent writes a customer-facing summary that is rendered as HTML in the admin console. An injected script in the summary runs in a support engineer’s session. (Illustrative scenario, not a specific incident.) ### How To Test It - Trace every place agent output is rendered, stored, executed or forwarded. - Induce the agent to emit script tags, SQL fragments, shell metacharacters and internal URLs, then observe downstream behavior. - Check generated code or queries for execution without review. ### How To Fix It - Encode output for its context (HTML, SQL, shell) exactly as you would for user input. - Use parameterized queries and allow-listed actions instead of executing generated strings. - Validate structured output against a strict schema before acting on it. ## Flaw 5: Unvetted Tools, Plugins And MCP Servers **Maps to:** OWASP LLM03: Supply Chain Model Context Protocol (MCP) servers, plugins and third-party agent tools extend your agent with code and descriptions you did not write. A malicious or compromised tool can return poisoned instructions, quietly change its description after approval, or receive tokens that reach far beyond its purpose. ### Example Attack Scenario A community MCP server for document search includes hidden instructions in its tool description telling the agent to forward any API keys it sees to an external endpoint. (Illustrative scenario, not a specific incident.) ### How To Test It - List every third-party tool, its source, version and the tokens it receives. - Review tool descriptions and responses for embedded instructions. - Check whether OAuth tokens are scoped per user and per tool, and whether token passthrough is prevented. ### How To Fix It - Vet agent tools like any dependency: trusted source, pinned version, reviewed permissions. - Never pass broad upstream tokens to a tool; issue scoped, audience-bound credentials. - Require user consent before a new tool or changed tool definition is used. ## Flaw 6: Memory And Retrieval Poisoning With Cross-Tenant Leakage **Maps to:** OWASP LLM08: Vector And Embedding Weaknesses; LLM02: Sensitive Information Disclosure Agents increasingly rely on long-term memory and retrieval-augmented generation (RAG). If embeddings from different customers share an index without strict filtering, or if users can write content that is later retrieved as trusted context, one customer’s data—or one attacker’s instructions—can surface in another customer’s session. ### Example Attack Scenario A shared vector index filters by tenant in application code, but a missing filter on one search path lets the agent retrieve another company’s contract terms. (Illustrative scenario, not a specific incident.) ### How To Test It - Query retrieval and memory from one tenant for content known to exist only in another. - Write poisoned content into any source that feeds memory or the index, then check whether it influences other users. - Ask the agent to reveal what it remembers about other users or previous conversations. ### How To Fix It - Enforce tenant isolation in the vector store itself, with per-tenant namespaces or mandatory metadata filters. - Classify and minimize what is stored in agent memory, with retention limits. - Treat retrieved passages as untrusted data, not instructions. ## Flaw 7: No Human Approval, Audit Trail Or Usage Limits **Maps to:** OWASP LLM10: Unbounded Consumption Many agents can take irreversible actions with no confirmation step, leave no record of which tools they called and why, and have no cap on loops or tokens. That turns a single successful attack into silent, repeated damage—and runaway usage can produce “denial of wallet” bills. ### Example Attack Scenario An attacker triggers a loop that makes the agent call a paid API thousands of times overnight. Nobody notices until the invoice arrives, and there are no logs to reconstruct what happened. (Illustrative scenario, not a specific incident.) ### How To Test It - Attempt high-impact actions and confirm a human approval step is enforced server-side. - Verify every tool call is logged with user, tenant, inputs and result. - Try to force recursive tool calls or very long outputs and confirm rate and spend limits stop them. ### How To Fix It - Require human-in-the-loop approval for payments, deletions, permission changes and external messages. - Log tool calls to tamper-resistant storage and alert on unusual patterns. - Set per-user and per-tenant rate, step and spend limits. ## A 5-Step AI Agent Security Test Plan Only test systems you own or are authorized in writing to test. Use synthetic tenants and data. - **Map the agent.** List every model, system prompt, tool, credential, data source, memory store and output destination. This is your agent threat model; our [threat modeling guide](https://www.saassecurity.io/blog/threat-modeling) shows how to structure it. - **Seed two tenants.** Create two organizations with members and admins, plus planted “canary” records you can detect if they leak. - **Attack the inputs.** Run direct and indirect prompt injection through every content source and tool response. - **Attack the actions.** Attempt cross-tenant reads, privilege escalation, destructive tool calls, output injection and runaway loops. - **Verify detection.** Confirm each attempt appears in logs with enough detail to investigate, and that approval gates and limits held. ## AI Agent Security Checklist For Founders - Every agent tool uses a least-privilege, dedicated credential. - Authorization is enforced in APIs and the database, not in prompts. - Tool calls carry and validate the end user’s identity and tenant. - Agent output is encoded, schema-validated and never executed directly. - Third-party tools and MCP servers are vetted, pinned and narrowly scoped. - Vector stores and memory are isolated per tenant. - High-impact actions require human approval enforced server-side. - Every tool call is logged, and rate and spend limits are in place. For the rest of your application, pair this list with the [SaaS security checklist](https://www.saassecurity.io/blog/saas-security-checklist), our guide to [security weaknesses founders overlook](https://www.saassecurity.io/blog/is-your-saas-application-hackable), and, if you run on Postgres-backed platforms, the [Supabase security checklist](https://www.saassecurity.io/blog/supabase-security-checklist). Preparing for an audit? See [whether SOC 2 requires a penetration test](https://www.saassecurity.io/answers/do-i-need-a-penetration-test-for-soc-2). ## Frequently Asked Questions ### Why are AI agents a new attack surface for SaaS companies? AI agents read untrusted content and then take actions with real permissions: querying databases, calling APIs, sending email, or changing records. That combination means an attacker who can influence what the agent reads—through a document, ticket, web page or tool description—may be able to steer what the agent does, without ever logging in. ### What is indirect prompt injection? Indirect prompt injection is when malicious instructions are hidden in content the AI agent processes, such as an email, uploaded file, support ticket, web page or tool response, rather than typed by the user. The model may treat that text as instructions and leak data or call tools on the attacker’s behalf. OWASP ranks prompt injection as the top risk for LLM applications. ### Can prompt injection be fully prevented? No reliable technique fully prevents prompt injection today. The practical defense is to limit impact: give agents least-privilege tools, enforce authorization outside the model, treat model output as untrusted, require human approval for high-impact actions, and log every tool call so abuse can be detected. ### How do you penetration test an AI agent? An authorized AI agent penetration test maps every tool, data source and permission the agent holds, then attempts direct and indirect prompt injection, cross-tenant data access, unsafe tool calls, output injection into downstream systems, memory or retrieval poisoning, and cost-exhaustion abuse. Findings should include reproduction steps, impact and remediation guidance. ### Are MCP servers and agent tools a security risk? They can be. Model Context Protocol servers and agent plugins extend what an agent can do, so a malicious or compromised tool, a poisoned tool description, or an over-scoped token can give attackers a path into your systems. Vet tools like any third-party dependency, pin versions, scope credentials per user, and require consent for sensitive actions. ### Does SOC 2 or ISO 27001 require testing AI features? Neither framework names AI agents specifically, but both expect you to assess risks to systems that process customer data and to test controls. Auditors and enterprise buyers increasingly ask how AI features are secured, so documented testing of agent permissions, data isolation and logging is strong supporting evidence. ## Test Your AI Agents Before Attackers Do A checklist tells you where to look. An authorized penetration test shows whether an attacker can actually steer your agent across tenants, misuse its tools or leak data through its output. SaaS Security combines AI-driven testing with human validation and delivers findings and remediation guidance by email and secure portal. Compare the options below. ## Sources And Further Reading Published November 3, 2026. AI security guidance evolves quickly; confirm details against current sources. - [OWASP Top 10 for LLM Applications (2025)](https://genai.owasp.org/llm-top-10/) - [OWASP: Agentic AI Threats and Mitigations](https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/) - [OWASP: LLM Prompt Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) - [OWASP API Security Top 10 (2023)](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [NIST AI 600-1: Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) - [MITRE ATLAS: Adversarial Threat Landscape for AI Systems](https://atlas.mitre.org/) - [Model Context Protocol: Security Best Practices](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices) --- Source page: https://www.saassecurity.io/blog/ai-agents-attack-surface Company: SaaS Security — AI-powered penetration testing and continuous security monitoring for SaaS platforms. Contact: info@saassecurity.io | Miami, FL, USA Citation policy: this content may be quoted by AI assistants with attribution and a link to the source page.