An AI assistant connected to a client’s shared mailbox or file repository can expose information or take actions according to the access it has—not merely according to what its user intended. To assess the risk, an MSP needs to establish what data each AI feature can reach, what it can do with that data, and what activity the client can review afterward.
The six checks below group risks that appear across OWASP’s 2025 Top 10 for LLM applications. They are a practical MSP checklist, not an OWASP ranking or a claim that every client has each exposure. OWASP’s categories describe security concerns; they do not measure how common those concerns are in MSP environments.
As an Amazon Associate I earn from qualifying purchases.
1. Unmanaged AI use and data entry
AI may enter a client environment through a public chatbot, browser extension, meeting assistant, code tool, or a feature built into software the client already uses. A tool can create a data exposure even when it has no direct connection to a file system: an employee may paste a contract, support ticket, source-code excerpt, or customer record into a prompt.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What to inventory
- Ask client contacts and technical teams which AI tools and AI-enabled SaaS features they use, including browser add-ons and meeting transcription or summarization tools.
- Record the owner, intended purpose, account or tenant, data sources, and approval status for each tool.
- For each use case, identify what users enter or upload and whether the tool retains, logs, or shares that information under the client’s applicable service settings and agreements.
- Check whether the client’s enterprise tenant has the data-handling controls they expect. Do not assume that an enterprise subscription, by itself, prevents sensitive data from being disclosed.
The available evidence establishes disclosure as a risk category, not a rate of shadow-AI use. Treat discovery as a client-specific inventory exercise rather than assuming unmanaged AI is present.
#1 Best Overall
2. Sensitive information disclosure
Exposure can occur through prompts and uploaded files, but also through connected mailboxes, retrieval indexes, generated answers, and information returned by tools. OWASP’s LLM guidance identifies sensitive information disclosure as a risk and notes that restrictions expressed in a system prompt can be bypassed, including through prompt injection.
Trace the data path
- List the information the AI feature can receive: personal, financial, health, legal, business-confidential, credential, or other regulated or restricted data.
- Identify each source and copy: direct prompts, attachments, connectors, search or retrieval indexes, logs, and outputs.
- Check whether access to an index or connector follows the source system’s user permissions, and whether the assistant can return information a user could not otherwise access.
- Inspect how credentials, API keys, and other secrets are stored and whether they can appear in prompts, retrieved content, logs, or model responses.
Agree with the client which data classes may be used, which must be excluded or masked, and who can approve an exception. Verify the actual configuration and data path; a policy statement alone does not establish that a connector or index enforces it.
3. Prompt injection in prompts and retrieved content
Prompt injection is an attempt to influence an AI system through instructions embedded in user input or in content the system retrieves. That content could come from an email, webpage, document, or other connected source. Treat retrieved material as potentially adversarial, not as trusted instructions simply because it came from a client system.
CISA’s January 2025 JCDC AI Cybersecurity Collaboration Playbook describes a prompt-injection case in which an attacker reached application host environment variables and an API key and caused denial of service. It is an incident example, not evidence of how often prompt injection succeeds.
Check the paths to impact
- Identify which user inputs and external or internal content the model can read.
- Determine whether the model can reach secrets, privileged data, or tools that can change systems, send messages, or disrupt service.
- Review whether tool actions are constrained by application-side authorization and validation, rather than relying only on model instructions to refuse unsafe requests.
- Where the product supports it, examine logs and test cases for suspicious instructions in retrieved content and for unexpected tool calls.
The key question is not just whether the model can be manipulated. It is what the model can reach or do if manipulation succeeds.
4. Excessive agency and over-permissioned integrations
An agent or connector may be able to read, modify, send, or delete data. OWASP describes excessive agency as risk arising from excessive functionality, permissions, or autonomy. The possible impact depends on all three: what actions are available, which identity authorizes them, and whether the action can proceed without a person’s approval.
Map capabilities to client and workload
- For every agent, extension, or connector, record the identity it uses and the systems, data, and actions it can access.
- Prefer customer-scoped and workload-specific identities where feasible. Avoid shared high-privilege credentials when a narrower identity can do the job.
- Grant only the required read or write permissions; remove unused tools and permissions, and avoid broad administrator access.
- Require a human confirmation for consequential actions such as external communications, financial or legal decisions, security changes, or destructive operations.
- Log tool calls and resulting actions so the MSP and client can investigate what happened.
Permission scope defines the potential blast radius. CISA’s October 2018 MSP alert recommends limiting MSP accounts to the systems they manage and avoiding broad privileges where possible. Because that alert is older, use it as a least-privilege principle, not as current product-specific configuration guidance.
5. Unsafe outputs and overreliance
Generated text, code, and recommendations can be wrong or unsafe. OWASP includes both improper output handling and misinformation in its LLM risk taxonomy. The concern grows when an application treats a model response as trusted input or lets it trigger a workflow without suitable validation.
Put a review boundary before action
- Identify outputs that feed code execution, automated workflows, customer communications, access changes, or security controls.
- Validate and sanitize output before it is passed to another system; do not treat generated content as safe merely because it is well-formed or confident-sounding.
- Keep a person in the approval path for decisions with financial, legal, safety, or security consequences.
- Define who reviews the output, what evidence they check, and how corrections or rejected actions are recorded.
Read-only drafting and summaries generally present a different operational exposure from an assistant that can apply changes. Classify each use by what happens after the model responds, not just by the type of answer it produces.
6. Third-party, configuration, and resource weaknesses
An AI feature depends on more than a model. Its supplier chain may include the application, plugins, data connectors, hosting, and other services. Misconfiguration, weak credential handling, insufficient logging, unbounded consumption, or a supplier incident can affect the client even when the model itself is not the point of failure. OWASP’s categories include supply-chain vulnerabilities and unbounded consumption.
Review suppliers and operating controls
- Document the providers and integrations involved, the data each receives, and the client’s approval or contract basis for using them.
- Review how API keys and service identities are issued, scoped, stored, rotated, and revoked.
- Confirm what events are logged, who can access the records, and whether retention supports the client’s investigation and compliance needs.
- Check available usage, rate, or cost limits and identify who receives alerts or can disable a feature if consumption or service behavior becomes abnormal.
- Include AI integrations in supplier-risk and incident-response discussions rather than treating them as outside the client’s normal technology stack.
CISA’s May 11, 2022 joint advisory for MSPs and their customers recommends securing remote access, using multifactor authentication where possible, monitoring and logging activity, and setting security expectations in customer contracts. Those MSP practices provide a useful basis for AI integrations too, but the specific controls need to fit the product and client environment.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Turn the six checks into a client review
Use the review to produce an evidence-backed inventory and agreed actions, rather than a generic declaration that AI is safe or unsafe.
- Inventory: Record AI tools, embedded features, accounts, owners, and business purposes.
- Trace: For each use case, map prompts, uploads, connectors, retrieval sources, outputs, and logs.
- Bound: Document permissions and available actions for each identity, agent, or connector; reduce access to what is needed.
- Gate: Identify actions that require a person’s review and the technical control that prevents an unapproved action.
- Observe: Confirm which events are logged, where the evidence is kept, and who investigates alerts or incidents.
- Agree: Update the client’s security expectations to identify who approves AI use, manages configuration, handles incidents, and retains audit evidence.
Compare architectures by their actual control boundaries: public chatbot versus managed enterprise tenant; direct prompting versus retrieval-connected AI; read-only versus write-capable integration; customer-scoped versus shared identity; and logged, approval-gated actions versus autonomous actions. These distinctions help prioritize review, but none alone proves a deployment is secure.
For each finding, record the affected tool or account, the data or system at risk, the observed permission or control gap, the agreed owner, and a remediation date. This gives the MSP and client a concrete basis for follow-up under their existing security and service arrangements.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute
