What happens when the helpful chatbot on your website reads a poisoned document, quietly follows the hidden instructions inside it, and starts leaking customer records to an attacker? That is not a science-fiction scenario. It is the exact failure mode security teams now test for before signing a contract. If you are buying an AI chatbot in 2027, the demo will impress you. The security questionnaire is what protects you.
This guide walks through nine questions that separate a genuinely defensible deployment from a polished liability. Each one maps to a real, documented risk, and each one has an answer you can actually verify.
Why chatbot security became a procurement problem
A few years ago, a chatbot was a scripted decision tree. Today it is a language model with tools, memory, and access to your knowledge base. That shift changes the threat model completely. The OWASP Top 10 for LLM Applications now leads with prompt injection, followed by insecure output handling, training-data poisoning, model denial of service, supply-chain risk, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft. That list is the single best structure for a vendor questionnaire, and every question below traces back to it.
The rules also matter. The EU AI Act entered into force in August 2024 and applies in stages: prohibitions from February 2025, general-purpose model obligations from August 2025, most high-risk obligations from August 2026, and certain embedded high-risk systems from August 2027. A customer-service bot is usually not high-risk, but one used in hiring, credit, education, or services people depend on can be high-risk. Implementation timelines have faced political debate about simplification, so confirm the current status rather than assuming the dates are fixed.
The nine questions that actually change the outcome
1. Can content the bot reads steer it, in addition to users?
Direct prompt injection is a user typing “ignore your instructions.” Indirect prompt injection is far nastier: the model ingests a web page, email, PDF, or support ticket containing hidden instructions and obeys them. Researchers demonstrated working exploits against real LLM-integrated products in 2023, and a zero-click vulnerability in a major productivity assistant was disclosed in 2025.
No vendor can honestly claim complete prevention. Ask instead: what does the bot do when it encounters untrusted content, and what is the blast radius if it is fooled? Input filtering helps, but privilege separation and human approval for sensitive actions help more. Treat “we are immune to prompt injection” as a red flag, not a selling point.
2. Does the bot combine private data, untrusted content, and outbound communication?
Security researcher Simon Willison coined the term lethal trifecta in June 2025 for the combination of three capabilities: access to private data, exposure to untrusted content, and the ability to communicate externally. A bot with all three has structural exfiltration risk. A bot with only one or two is far easier to defend.
This is the most useful question in the entire list because it forces an architectural answer. Ask the vendor to draw the data flow. If the bot reads customer emails and can also send messages or call APIs, ask what stops it from forwarding a summary of your private data to an attacker-controlled address.
3. What can the bot actually do, and who approves it?
OWASP calls this excessive agency. A chatbot that can only draft replies is low risk. A chatbot that can issue refunds, reset passwords, modify records, or trigger workflows is an autonomous actor inside your systems. Ask for a written list of tools and permissions, whether they run with the user’s privileges or a service account, and which actions require human confirmation.
In practice, the strongest deployments start read-only and add write actions one at a time, each with an approval step. If a vendor cannot show you a permissions matrix, you are buying blind.
4. How is the bot hardened against attacks on its own infrastructure?
Security does not stop at the model. Look at the plumbing: is the API rate-limited, is authentication enforced per session, are prompts and secrets stored outside the model context, and is the vector database segmented from production systems? A DNS-layer review belongs here too, since hijacked resolution can redirect traffic away from legitimate endpoints. A DNS security checklist for hardening your resolver is a reasonable starting point for that conversation, and a managed detection and response checklist of questions to ask before you buy helps you judge whether the vendor’s monitoring is real or just a dashboard.
5. Where does conversation data go, and how long does it stay?
Conversation logs are full of personal data. Under GDPR, processing requires a lawful basis, and the EU AI Act adds transparency duties, including telling users they are interacting with an AI system. Ask four things: retention period, whether your data trains the vendor’s models, the full subprocessor list, and data residency options.
The training question is where buyers get surprised. Many contracts allow “service improvement” unless you opt out in writing. Get the opt-out in the contract, not in a sales call.
6. Which certifications are real, and which are self-attestations?
ISO/IEC 42001:2023 is the first certifiable international management-system standard for AI, and it pairs naturally with ISO/IEC 27001:2022 for information security. A certificate issued by an accredited auditor is a strong, checkable signal. A self-assessment is not the same thing.
Ask for the certificate, its scope, and its expiry date. Plenty of vendors say “aligned with ISO 42001” when they mean “we read the standard.” That distinction is worth real money in a breach.
7. How does the vendor detect and respond to AI-specific attacks?
Traditional security monitoring looks for bad packets. AI attacks look like ordinary text. Ask whether the vendor maps detections to MITRE ATLAS, the public knowledge base of real-world AI attack techniques, and whether it logs prompts, tool calls, and model outputs for investigation.
Then ask the harder question: what is the incident response playbook when a prompt injection succeeds? Who is notified, how fast, and can the vendor reconstruct the conversation that caused it? A vendor that cannot answer this has never rehearsed a bad day.
8. What happens when the model changes or the vendor disappears?
Foundation-model providers update, deprecate, and re-tune models with limited notice. Your carefully tested bot can behave differently overnight. Ask for version pinning, a change-notification SLA, and a documented evaluation suite that runs after every model update.
Then ask about exit. Can you export your knowledge base, conversation history, and configuration? Is there a data-portability clause? Vendor concentration risk is real, and the time to negotiate an exit plan is before you need one.
9. How does the vendor govern risk internally?
The NIST AI Risk Management Framework and its Generative AI Profile offer a voluntary structure built around four functions: Govern, Map, Measure, and Manage. Asking which functions the vendor documents is a fast way to tell a mature program from a marketing page. You do not need the vendor to be certified against it. You do need evidence that someone owns AI risk, measures it, and reports on it.
Red flags that should end the conversation
Some answers tell you more than any brochure. A vendor who claims zero prompt-injection risk, refuses to name subprocessors, cannot produce an ISO certificate scope, or has no answer for model deprecation is not ready for regulated buyers. So is a vendor who treats the security questionnaire as an obstacle rather than a design document.
The reverse is also true. A vendor who pushes back on your questions, asks what your threat model is, and offers to run a joint tabletop exercise is usually the one worth signing with.
How to run the evaluation without wasting a quarter
Practical buyers rarely get to test everything. A workable sequence looks like this:
- Send the nine questions as a written questionnaire and require written answers.
- Score each answer as documented, claimed, or unknown, and treat unknown as a no.
- Request the ISO certificate scope and the subprocessor list, then verify both independently.
- Run a red-team session against a sandbox, including an indirect injection test using a document with hidden instructions.
- Confirm the contract covers training opt-out, retention, version pinning, and data portability.
- Re-test after the first model update, because that is when behavior drifts.
That sequence takes weeks, not months, and it catches most of the failures that show up in post-incident reviews.
Hardware and infrastructure questions buyers forget
Chatbot security does not exist in a vacuum. If you self-host models or run inference on your own hardware, the same compatibility discipline that applies to any upgrade applies here. Teams planning GPU refreshes in 2027 should run an AMD vs Intel CPU compatibility check before upgrading, and anyone comparing cards for inference workloads will want a RTX 5070 vs 5070 Ti compatibility check before committing budget. Power and thermal headroom matter as much as raw throughput, which is why a power efficiency check on the RTX 4090 versus the RTX 5080 is worth doing early rather than after the rack is full.
At the high end, the same logic applies to flagship cards. A compatibility check on the RTX 5090 versus the 4090 saves surprises, and buyers weighing newer silicon should run an RTX Spark versus RTX 5090 compatibility check before assuming the newest part fits the workload. None of this replaces the nine security questions, but infrastructure you cannot patch or power is its own kind of vulnerability.
Conclusion
Buying an AI chatbot in 2027 is a security decision disguised as a software purchase. The demo shows what the bot can do when everything goes right. The nine questions above show what happens when everything goes wrong, and that is the version of the product you actually live with.
Start with the lethal trifecta. If the bot touches private data, reads untrusted content, and can talk to the outside world, demand a specific architectural answer. Then work through agency, data handling, certifications, detection, model change, governance, and exit. Vendors who answer well are safer, and their products are usually better, because teams that think hard about failure modes tend to build more carefully.
FAQ
What is prompt injection in an AI chatbot?
Prompt injection is an attack where hidden or crafted text makes the model follow instructions it should ignore. It can be direct, from a user, or indirect, from a document, web page, or email the bot reads. No reliable full prevention exists, so buyers should focus on limiting what the bot can do rather than what it can say.
Is a customer-service chatbot high-risk under the EU AI Act?
Usually not. A general customer-service bot typically falls outside the high-risk category, but a bot used in hiring, credit scoring, education, or access to basic services may be classified as high-risk. Classification depends on the use case, so confirm your specific deployment rather than assuming.
Can a vendor honestly claim to be immune to prompt injection?
No. Prompt injection remains an unsolved class of vulnerability, and current defenses are partial at best. A vendor claiming complete immunity is signaling either ignorance or dishonesty. Better answers describe privilege separation, human approval steps, and constrained tool access.
What is the lethal trifecta, and why does it matter?
It describes the combination of access to private data, exposure to untrusted content, and the ability to communicate externally. A chatbot with all three capabilities has structural data-exfiltration risk. Removing any one of the three substantially reduces the danger, which makes it a practical architectural question.
Is ISO 42001 certification better than a self-assessment?
Yes, when it is genuine. ISO/IEC 42001:2023 is a certifiable management-system standard for AI, and certification requires an accredited auditor. Many vendors hold only self-attestations while using similar language. Always ask for the certificate, its scope, and its expiry date.
How often should chatbot security be re-tested?
At minimum, after every model update or version change, and at least annually otherwise. Model behavior can shift without notice, and prompt-injection techniques evolve quickly. A written evaluation suite that runs on each update is the most reliable way to catch drift before your customers do.
