AI security risks in a mid-market company

The main AI security risks for a mid-market company are data leaking into tools nobody reviewed, AI vendors with weak data terms, prompt injection through content the model reads, and agents with more access than the task needs. Most of the exposure comes from adoption that happened without an inventory or a review, not from a sophisticated outside attacker.

That is good news in one sense. The fixes are mostly governance and application security, and both are cheaper than an incident.

Risk one: data leaking into unreviewed tools

A member of staff pastes a customer contract into a free chatbot to summarise it. The summary is fine. The problem is that the document may now sit on a vendor's servers under terms nobody negotiated, and the company has no record that it left.

The controls are straightforward: an approved tool list, a data classification rule that says what may go where, retention settings reviewed before rollout, and training that names real examples. Technical controls help too, such as blocking unapproved AI domains at the network or browser layer, but policy comes first because staff need a sanctioned way to do the task.

Risk two: AI vendors with weak data terms

Free and low-cost tiers often reserve broader rights over input data, and the terms change. Before a tool touches business data, the review should answer:

• Does the vendor train models on our data, and can we turn that off in writing?
• How long is data retained, and can we delete it on request?
• Which subprocessors and model providers sit behind the product?
• Where is data processed, and does that cross a border we care about?
• What are the breach notification obligations and timelines?
• Which security attestations or audit reports exist, and what do they cover?
• Can we export our data and our usage history on exit?

Record the answers and the date. A vendor review is a snapshot, not a permanent approval.

Risk three: prompt injection and untrusted content

An LLM does not separate instructions from data. If the model reads a web page, an email, a PDF, or a support ticket, text inside that content can try to redirect what the model does. This is prompt injection, and it matters most when the model can act, not just answer.

Practical limits:

• Do not give a model write access to systems unless the workflow needs it.
• Require human confirmation for money movement, access changes, and outbound messages.
• Treat retrieved content as untrusted by default.
• Log the tool calls the model makes so you can reconstruct what happened.

LLM security is mostly application security: what the model can read, what it can do, and who approved it.

Risk four: over-permissioned agents and integrations

An AI assistant wired into a company workspace often inherits the permissions of the person who set it up. That can mean read access to every document and write access to shared drives. Agents that take actions have the same problem with higher stakes.

Scope every integration to the task. Use a dedicated service account rather than a person's credentials. Grant read-only where read-only is enough. Keep a list of what each integration can reach, and know how to switch it off. ## Risk five: the AI supply chain

Model updates, third-party plugins, and connectors are software supply chain. They change without your involvement. Pin versions where the platform allows it, require notice of material changes in contracts, and re-review the integrations that touch sensitive data when the vendor ships a new capability.

Risk six: no logging, so no investigation

If nobody records which prompts, tools, and outputs were involved in a workflow, an incident review becomes guesswork. Log enough to answer who used which tool on what data, and keep it for a defined period. Balance that against privacy obligations: log metadata where full content is not necessary.

Risk seven: shadow AI

Shadow AI is any AI use the company has not approved. It hides in browser extensions, embedded features inside existing SaaS, personal accounts, and team-level subscriptions paid on a corporate card. Find it through SaaS admin consoles, expense reports, network logs, and a plain question to department heads. Then either approve it, fix it, or replace it with something sanctioned.

A short vendor review checklist

• Training on our data: allowed or contractually excluded.
• Retention and deletion: documented, with a deletion mechanism.
• Access controls: SSO, role-based access, admin logging.
• Subprocessors: named and reviewed.
• Security attestations: available and current.
• Breach notification: obligation and timeline in the contract.
• Data residency: known and acceptable.
• Exit: export and deletion terms.

Where to start

You do not need a policy for every possible tool. Start with the inventory, tier the data each use case touches, review the ten vendors that matter most, and put technical limits on the workflows that can act on systems. That sequence finds the real exposure quickly.

The AI Security & AI Governance service runs that work as a defined engagement: inventory, risk tiering, acceptable-use policy, vendor review, and board-ready evidence. If you are also preparing for an audit, the Compliance & Audit Readiness service maps the same evidence to SOC 2, ISO 27001, and NIST CSF. Request a briefing to talk through the current state.