How to Secure AI Chatbots Against Cyberattacks

An AI chatbot is a public, untrusted input surface connected to a model that may have access to private data and tools. That combination needs the same discipline as any internet-facing application, plus controls for the model-specific risks.

Start with identity and tenancy

Know who is talking to the bot before it retrieves anything. Anonymous chat can be fine for marketing, but it must not reach customer records, internal documents or tools. Authenticate the user, resolve the tenant, and scope every retrieval and tool call to that tenant.

Do not let the model choose the tenant from the conversation. Tenant selection is an authorization decision made by your code from the session, never from a string the model can produce.

Treat every message as hostile

The user message is attacker-controlled. So are uploaded files, pasted text, fetched URLs, retrieved documents and tool results. Screen the whole set for prompt injection, encoded payloads and instructions embedded in content.

A chatbot that summarizes a web page is an indirect injection target even if its own users are trusted. The page is the attacker.

Keep secrets out of the prompt

System prompts are not a vault. Do not put API keys, database credentials or internal URLs in them. Models can be persuaded to repeat context, and logs may retain it. Use short-lived credentials held by the application, injected into a tool call only after authorization.

Constrain retrieval

Retrieval is where data leaks happen. Index only what the user is allowed to see, filter by tenant and permission at query time, and return the minimum number of chunks. Do not rely on the model to ignore a document it should not have received.

Control the output path

The completion is untrusted. If you render markdown, sanitize HTML. If you turn links into clickable URLs, validate the destination. If you pass the output to another system, treat it as user input: parameterize queries, avoid shell execution, and never eval model text.

For customer-facing chat, also screen for abuse categories and personal data, and redact where policy requires it. Keep the decision and the reason, not just the final text.

Add abuse and cost controls

Public chatbots attract automated abuse. Rate limit per IP and per account, cap message length, cap conversation length, and set per-session token and cost ceilings. Detect loops and repeated retries. A denial-of-wallet attack does not need a sophisticated prompt; it needs volume.

Log enough to investigate

Record the user/tenant, input hash, retrieval identifiers, controls that ran, verdict, model and policy version, and action. Avoid storing raw sensitive content longer than necessary. The goal is to reconstruct the decision without turning the log into a second data breach.

Test like an attacker

Run a small adversarial suite on every release: direct overrides, roleplay jailbreaks, encoded instructions, hidden text in documents, requests for the system prompt, attempts to reach another tenant, and payloads that try to make the bot emit a URL. Include benign security questions to catch false positives.

A minimum viable baseline

• —Authenticated, tenant-scoped retrieval
• —Injection screening on user and retrieved content
• —No secrets in the prompt
• —Output sanitization and URL validation
• —Per-session rate and spend ceilings
• —Append-only decision log
• —A tested incident path for disabling the bot

None of these require a large team. They require deciding that the chatbot is a security boundary, not a demo.