The AI Attack Surface in 2025: What Enterprises Got Wrong

The speed of enterprise GenAI adoption in 2024 and 2025 created a predictable security gap. According to Gartner's 2025 AI security survey, 68% of organisations that deployed LLM-integrated applications did so without a formal security review of the deployment architecture. The same survey found that 41% of security teams had no visibility into which AI models and services were being used across their organisation. The attack surface expanded faster than the controls that should accompany it.

This report draws on MITRE ATLAS, OWASP LLM Top 10, Google's Threat Horizons reporting, and our own assessment work to document the most commonly exploited patterns in enterprise AI deployments observed in 2025.

Shadow AI: The Ungoverned Deployment Problem

The most prevalent finding in enterprise AI security assessments this year was not a specific technical vulnerability but a governance failure: employees deploying AI tools and integrations outside of any IT or security review process. Gartner found that large enterprises had an average of 74 distinct AI tools in use, of which only 31 were sanctioned by IT. The remaining 43 were shadow deployments, many of them browser extensions, third-party integrations, or SaaS products that had added LLM features without updating their data processing agreements.

The security implications are significant. Shadow AI tools often receive sensitive internal data — customer records pasted into a chatbot for summarisation, code containing credentials uploaded for review, internal documents sent to an AI writing assistant. Most of these tools are not covered by corporate data handling policies, and many transmit data to third-party model providers under the provider's own terms rather than the enterprise's data processing agreements.

RAG Pipeline Authorisation Failures

Retrieval-Augmented Generation (RAG) allows LLM applications to retrieve relevant documents from internal knowledge bases before generating a response. The pattern is powerful but introduces a critical security requirement: the retrieval layer must enforce the same access controls as direct document access. In practice, most RAG deployments we assessed were not meeting this requirement.

The most common pattern: a RAG system that indexes all documents in a SharePoint or Confluence instance and allows any authenticated user to query across the entire corpus, regardless of their individual document permissions. An employee with access to general company policies could retrieve excerpts from board meeting minutes, M&A documentation, or HR records by crafting sufficiently specific queries — not because the LLM was exploited, but because the retrieval layer had no per-user permission model.

# Bad: retrieval without access control
def retrieve_documents(query: str, vector_store) -> list[str]:
    results = vector_store.similarity_search(query, k=5)
    return [doc.page_content for doc in results]
    # Returns documents regardless of who is asking

# Better: enforce caller identity at retrieval time
def retrieve_documents(
    query: str,
    vector_store,
    user_id: str,
    permission_service: PermissionService,
) -> list[str]:
    results = vector_store.similarity_search(query, k=20)
    # Filter to only docs the caller is authorised to read
    authorised = [
        doc for doc in results
        if permission_service.can_read(user_id, doc.metadata["source_id"])
    ]
    return [doc.page_content for doc in authorised[:5]]

Prompt Injection at Scale

Google's Threat Horizons H1 2025 report documented the first confirmed use of prompt injection in financially motivated attacks against enterprise applications. The attack pattern involved injecting instructions into documents processed by enterprise LLM pipelines — specifically, contract review and email summarisation workflows — to redirect outputs in ways that influenced downstream business decisions.

MITRE ATLAS catalogued 23 confirmed prompt injection incidents in 2025 where the injection succeeded in causing unintended tool execution by an AI agent. The highest-severity cases involved agents with access to email sending, calendar management, or internal ticketing systems — tools that allow an injection to have real-world consequences beyond just returning incorrect text.

Model and API Key Exposure

IBM X-Force found OpenAI, Anthropic, and AWS Bedrock API keys in 12% of the public repositories they scanned as part of their credential exposure monitoring programme. The exposure rate for AI provider keys grew faster than any other credential category in 2025, driven by the volume of developers experimenting with LLM integrations and committing .env files or hardcoded keys to public repositories.

Exposed API keys carry two distinct risks: cost abuse (using the key to run inference at the victim's expense) and data access (using the key to access fine-tuned models, uploaded files, or conversation history stored by the provider). Both have been observed in the wild in 2025.

# Find exposed AI provider credentials in git history
# (run against your own repositories as part of your security programme)

# Gitleaks with AI provider rules
gitleaks detect --source . --log-opts="--all" 2>&1 | grep -E "openai|anthropic|bedrock|cohere|huggingface"

# Patterns that indicate AI key exposure:
# sk-[a-zA-Z0-9]{48}              OpenAI API key
# sk-ant-[a-zA-Z0-9-_]{95}        Anthropic API key
# AKIA[0-9A-Z]{16}                AWS access key (may be Bedrock)

# If found: rotate immediately, then check provider usage logs for abuse

AI in the Hands of Attackers

CrowdStrike's GTR 2025 documented a meaningful increase in AI-assisted social engineering. The most impactful technique was not sophisticated jailbreaking of public models but rather the use of deepfake audio in targeted vishing (voice phishing) calls. Several high-value business email compromise cases in 2025 were preceded by a vishing call using an AI-generated voice cloned from publicly available audio of a target executive — a technique that CrowdStrike attributes to at least four distinct financially motivated threat groups.

What Good AI Security Governance Looks Like

1. 01Maintain an AI tool inventory. You cannot govern what you have not counted. Implement a lightweight approval process for new AI tool adoption that captures what data the tool receives and what its data handling terms are.
2. 02Apply data classification before deploying RAG. Only ingest data into a knowledge base at a sensitivity level appropriate for the broadest user group that will query it. Use separate knowledge bases for different trust levels.
3. 03Treat all LLM agent tool access as privileged. Apply least-privilege to every tool exposed to an LLM agent. An agent that only needs to read documents should not have write access. An agent that only needs internal data should not have internet access.
4. 04Rotate AI provider API keys on a schedule and monitor usage. Set spend alerts and flag unusual inference volume. A sudden spike in API usage on a development key is an indicator of key abuse.
5. 05Test AI-integrated applications for prompt injection before production deployment. This requires manual testing by someone familiar with the attack class — automated scanners do not reliably detect indirect injection via retrieved content.