Marvel Advisors
Contact us
AI Security

Securing AI Adoption in Your Business: Shadow AI, Data Leakage, and Vendor Risk

Oct 29, 2026 ยท By Marvel Advisors

Most businesses did not decide to adopt AI. It showed up on its own: someone pastes a contract into a chatbot to summarize it, a browser extension offers to "rewrite this email," or a software tool you already pay for switches on a new AI assistant. None of that is a problem by default. The problem is adopting AI without knowing where your data goes, who can reach it, and what the tool is allowed to do.

Start by finding the shadow AI

"Shadow AI" is AI use your organization has not reviewed or approved. It usually takes three forms:

  • Personal accounts on public AI tools, used for work tasks.
  • AI features inside approved software that were turned on by a vendor update.
  • Browser extensions, plug-ins, and integrations that connect AI services to email, files, or chat.

You cannot manage what you cannot see. Use what you already have: web proxy or DNS logs, your identity provider's list of third-party app consents (the "sign in with" grants employees have approved), endpoint software inventories, and expense reports. Then ask people directly with a short, non-punitive survey; it also tells you which tools are worth approving properly.

Understand how data leaks into AI tools

NIST's Generative AI Profile lists data privacy (leakage and unauthorized use or disclosure of sensitive data) and information security among the core risks of generative AI. In practice, leakage happens in a few predictable ways:

  • Prompts and uploads. Whatever an employee pastes or uploads (customer records, source code, financials, credentials) leaves your control and is handled under the tool's terms, which may include retention or use for model improvement.
  • Over-broad connections. An AI assistant connected to a shared drive or mailbox can surface anything its permissions allow, including files that were "secured" only because nobody knew where they were.
  • Outputs. The OWASP Top 10 for LLM Applications ranks Sensitive Information Disclosure second, behind Prompt Injection: crafted content in a document, web page, or email can manipulate an AI tool into revealing or acting on data it should not.

Joint guidance from CISA, NSA, FBI and international partners on AI data security makes the same point: protecting the data that feeds AI systems is central to using them safely.

The fix is not to ban AI. It is to decide which data classes may go into which tools, and to enforce that where you can.

Apply access control to AI like any other system

AI tools should not get a pass on the basics:

  • Single sign-on and MFA for every approved AI tool, so access ends when employment ends.
  • Least privilege for connectors. If an AI assistant indexes your files, it inherits your permission mistakes. Clean up over-shared folders before connecting it, not after.
  • Limit autonomy. OWASP calls this Excessive Agency: an AI agent that can send email, move money, or change records needs the same approval steps a person would need.
  • Logging. Make sure you can see who used the tool, with what data, and what it did. If a vendor cannot provide usable logs, factor that into your decision.

Review AI vendors before you sign

Treat AI tools as third-party risk, because that is what they are. NIST also flags value chain and component integration (unclear upstream components and weak supplier vetting) as a generative AI risk. Useful questions for any AI vendor:

  1. Is our data (prompts, files, outputs) used to train or improve models? Can we opt out contractually, not just in a settings page?
  2. How long are prompts and outputs retained, and where are they stored?
  3. Which sub-processors or underlying model providers touch our data?
  4. What security attestations or independent assessments can you share?
  5. Do you support SSO, role-based access, audit logs, and admin controls over AI features?
  6. How will you notify us of a security incident, and how quickly?

Also review the AI features of tools you already use. A vendor's new AI add-on may be covered by different terms than the product you originally approved.

Write an acceptable-use policy people can follow

A good AI acceptable-use policy fits on one or two pages. It should state:

  • Approved tools and how to request a new one.
  • Data rules in plain terms, for example: "Never enter customer personal data, credentials, or confidential financials into an unapproved AI tool."
  • Human review. AI output can be confidently wrong; NIST calls this confabulation. People remain responsible for anything they send, publish, or decide.
  • Disclosure expectations for AI-generated content where it matters to customers or partners.
  • How to report a mistake, such as pasting the wrong file, without fear of punishment. Fast reporting limits damage.

Pair the policy with short training and revisit it at least once a year. AI tools change faster than most policies.

Quick checklist

  • Inventory AI tools in use, including personal accounts, extensions, and AI features in existing software
  • Classify data and decide which classes are allowed in which AI tools
  • Require SSO and MFA for approved AI tools
  • Fix over-shared files before connecting AI assistants to them
  • Require human approval for AI agents that take actions
  • Run AI vendors through third-party risk review, including training-data and retention terms
  • Publish a short acceptable-use policy and a no-blame way to report mistakes
  • Review the inventory and policy at least annually

Where a risk assessment fits

AI adoption is a change to your environment, and the clearest way to see its impact is to look at it alongside everything else: your data, your identities, your vendors, and your existing controls. A risk assessment can map where AI tools touch sensitive data, identify the gaps that matter most, and give you a prioritized plan, so you can keep the productivity benefits without guessing about the risk.

Sources