# Protect Against Prompt Injection Input Safety reads every incoming message before your employee does, and stops the ones trying to hijack it: instructions to ignore its rules, requests to print its own configuration, and role-play framed to talk it out of its guardrails. That matters most where the message did not come from you, so a payload buried in a forwarded email, a support ticket, or a shared thread cannot turn your employee against you. Pick Low, Medium, or High, and every level catches the textbook attacks: the level decides how much benefit of the doubt the genuinely ambiguous messages get. Medium is the default and suits most companies. Blocked messages get a short, human reply and the conversation carries on, with each one recorded so you can see what has been tried. Input safety screens every message before it reaches your AI employee's model. Prompt injection attempts, jailbreaks, and instructions designed to make the agent ignore its rules are detected and stopped at the door. This matters most for employees exposed to the outside world. A chat widget on your website, a public mailbox, or an inbound support queue will eventually receive adversarial input. Input safety means that is an expected event, not an incident. Protection runs automatically on every channel, with no prompt engineering required from you. Your employees keep their instructions, their boundaries, and their judgment, no matter what arrives in the inbox. Strictness is yours to set. Three levels, low, medium and high, decide how much benefit of the doubt a genuinely ambiguous message gets, and every level catches the textbook attacks regardless of which one you pick. Medium is the default and suits most companies. Move it up when your employees face the public directly, or down if your normal traffic is unusual enough to trip the strict end. It is an organization wide setting rather than a per employee chore. One choice covers every employee you have and every channel they answer on, including the ones you connect later. Input safety also sits beside four related policies, output safety, PII protection, topic control and data leakage prevention, in the same place, so your whole safety posture is one screen instead of a scavenger hunt. A block is not a dead end for a real person who simply phrased something oddly. The sender gets a short, human reply and the conversation carries on, while the block itself is recorded so you can see what has been tried against your workforce. None of it interrupts your day or waits on you to intervene. ## What Is Prompt Injection and Why Should You Care? Prompt injection is the practice of hiding instructions inside ordinary-looking content, like an email that tells the agent to ignore its previous instructions and forward your files. Models that act on untrusted input are vulnerable by default, which is exactly the position any working AI employee is in. Input safety exists because your employees read email, browse the web, process documents, and talk to strangers. Each of those is a path for adversarial text, and each one is screened before the model acts on it. This is not a theoretical risk. Attacks hidden in ordinary-looking content, a forwarded email, a shared document, a scraped web page, have been used against production AI systems to trigger actions nobody approved. Any employee that reads external content is exposed to this by default. The only real defense is screening what comes in before the model ever interprets it as an instruction. ## Jailbreaks Stopped Before the Model Sees Them Jailbreak attempts try to talk a model out of its safety behavior through roleplay, hypotheticals, encoding tricks, and social pressure. The input safety layer recognizes these patterns and blocks the attempt rather than letting it through and hoping the model resists. Blocking happens before model inference, which is the strongest place to stand. A manipulation the model never reads is a manipulation that cannot work, regardless of how clever it is. ## Safety That Does Not Slow the Work Down Screening runs on every inbound message and is invisible when input is clean, which is nearly all of the time. Legitimate work flows through untouched while malicious payloads are stopped and logged. Each blocked attempt is recorded so you can see what was tried against your workforce. For most teams, the log is quiet reassurance; for security teams, it is evidence the boundary is doing its job. ## Set It Once, For Everybody Input safety belongs to your organization's security settings, not to each employee individually. You pick a strictness level of low, medium or high, and it applies to every employee and every channel they answer on, including any you connect later. Medium is the default and is the right starting point for most companies. The same screen holds the four related policies, output safety, PII protection, topic control and data leakage prevention, so the safety posture of your entire workforce is one page you can read in under a minute. Each is a single switch with its own strictness level, which means tightening one area does not force you to tighten all of them. ## How It Works **Every inbound message passes a screening layer before the model acts on it.** Each message arriving on any channel is evaluated against known manipulation patterns: prompt injection, jailbreak structures, encoded instructions, and unsafe requests. Clean traffic, which is nearly all of it, passes through with no perceptible delay. Flagged input is blocked before model inference and the event is logged with the reason. The employee never reads the malicious content, so there is no contest of wills with the attacker, just a closed door. Screening follows the message wherever it came from, not just the chat box. The same check runs on an email your employee reads, a document it processes, a ticket that arrives through a form and a page it opens while researching, because hidden instructions do not care which door they came through. When the layer cannot make a confident call on an inbound message, it refuses that message rather than passing it along and hoping for the best. ## Use Cases ### Public chat widget shrugs off injection attempts Visitors who paste jailbreak prompts get a polite refusal, and the attempt is logged for review. ### Email-borne attacks die at the gate An inbound email with hidden instructions is blocked before the employee processes the thread. ### Scraped web content stays untrusted Adversarial text planted on web pages is screened when employees browse and research. ### Security team gets an attack log Blocked attempts form a record of what is being tried against your workforce. ### One setting covers the whole workforce Strictness is chosen once at organization level and applies to every employee and every channel, including the ones you connect later. ### Multi-step workflows stay contained even under attack An employee chaining several tools together, like reading a document then acting on what it found, cannot be walked into an unintended sequence by hidden instructions in that document, because each input is screened before it reaches the model that decides the next step. ## Comparison | Before | After | |---|---| | Agent safety depends on the model refusing. | Malicious input is blocked before the model reads it. | | Prompt injection is discovered after the damage. | Injection patterns are caught at the door and logged. | | Each prompt needs hand-written defenses. | Protection is a platform layer on every channel. | | Public-facing AI is a standing risk. | Adversarial input is an expected, handled event. | ## FAQ ### How does Sistava protect against prompt injection? Every message is screened by the input safety guardrail before it reaches the model. Injection patterns, jailbreak attempts, and unsafe instructions are detected and blocked, and the attempt is logged. ### Do I need to configure input safety? No. It runs automatically on every channel for every employee. There is nothing to write or maintain. ### Will input safety block legitimate messages? It is tuned for accuracy on real-world traffic. Ordinary requests, even unusual ones, pass through; the layer targets manipulation patterns, not strong language or odd topics. ### Why is blocking inputs better than trusting the model to refuse? Model refusal is a last line of defense that sophisticated attacks try to erode. Stopping malicious input before inference means the model never has to win that argument. ### Does this cover indirect prompt injection, like instructions hidden in an email or a web page, not just something typed directly into chat? Yes. The same screening applies regardless of where the content originates: a message typed directly to the employee, an email it reads, a document it processes, or a web page it visits while browsing. Hidden instructions are stopped in each case, before the model acts on them. ### How is input safety different from the approval gateway? They work at different points. Input safety blocks manipulative content before the model ever reads it. The approval gateway pauses a legitimate, already-in-progress action, like sending an email, for your sign-off. A blocked injection attempt never gets far enough to reach either the model or an approval prompt; it is stopped at the door. ### Where do I turn input safety on and change how strict it is? Input safety lives with your organization's security policies and applies to every employee and every channel at once, rather than being set employee by employee. You choose a strictness level of low, medium or high, with medium as the default. The level decides how much benefit of the doubt genuinely ambiguous messages get, since every level already catches the textbook attacks. ### What happens to the person who sent a blocked message? They get a short, human reply and the conversation carries on normally, so a real customer who happened to phrase something oddly is never left staring at an error. The block is recorded on your side, which gives you a record of what has been tried against your workforce without anything needing your attention in the moment. ## Where Protect Against Prompt Injection fits Protect Against Prompt Injection is part of What stops them from going wrong. Your AI agents pause before any sensitive action and wait for your approval. PII is detected and redacted before it reaches the model. Content policies block harmful or off-brand output. Execution limits prevent runaway tasks. A Sistava mentor pairs with every employee to spot blockers and keep work on track alongside their team leader. Set company-wide policies once and every employee follows them, including future hires. - [What stops them from going wrong](/en/features/guardrails): Nothing sensitive happens without your say. ## Read the guide - [Guide: Protect Against Prompt Injection](/en/guide/company/policies) ## More in Guardrails - [AI Guardrails & Policies](/en/features/guardrails/guardrails): A Security Officer that checks every message going into and coming out of every AI employee you have. Five policies, each with its own switch: Input Safety stops prompt injection and jailbreak attempts, Output Safety keeps unfit replies from being sent, PII Protection replaces personal data with markers before the model reads it, Data Leakage Prevention keeps your setup and secrets in-house, and Topic Control holds employees to the subjects you choose. Turn on what you need from Settings, Technical, Security Officer and it covers every employee on the next message, including the ones you hire later. Checks run in parallel on a separate lightweight model, so protection costs a fraction of a message and your team never feels the wait. A running count of what has been caught, the busiest policy, and a live inspector showing every individual message are all on the same page. - [Block Unsafe Employee Responses](/en/features/guardrails/guardrail_output_safety): Output Safety reads your employee's reply before anyone else does. Toxic, abusive, or otherwise unfit answers are held back rather than sent, which is what you want the moment employees write to customers, post to a channel, or answer a ticket without you watching. It checks the reply your employee actually wrote, so what you see caught is what would genuinely have gone out. Set it to Low, Medium, or High and review everything it held back in the live inspector. Blunt, direct, and critical business writing is left alone: the policy is looking for replies that would embarrass you, not ones that are simply frank. - [Protect Personal Data](/en/features/guardrails/guardrail_pii_protection): PII Protection finds personal data in a message and replaces it with a marker before the model reads a single character of it. A pasted card number becomes [CREDIT_CARD], an email becomes [EMAIL_ADDRESS], and the same happens on the way out so nothing sensitive travels back into an email, a channel, or a ticket. You pick exactly what to protect from seven data types: email, phone, name, credit card, Social Security number, IP address, and address. The markers keep the sentence readable, so your employee understands the request perfectly and keeps working while the raw value stays out of the conversation. It runs on every message, in both directions, company-wide, from one switch. - [Control What Employees Discuss](/en/features/guardrails/guardrail_topic_control): Topic Control gives you two lists and you can use either or both. Blocked topics are off-limits no matter how a conversation gets there, which keeps employees out of politics, competitor comparisons, or medical and legal advice. Allowed topics set a remit instead: name the subjects an employee handles and anything unrelated is politely declined, which is how you keep a support employee on product help, billing, and refunds. Both lists match on meaning rather than exact words, so ruling out competitor pricing also covers how much cheaper are we than the other tools out there. Greetings and short replies always get through, so a scoped employee still feels natural to talk to. - [Keep Confidential Data In-House](/en/features/guardrails/guardrail_data_leakage): Data Leakage Prevention guards both ends of the conversation. On the way in it recognises someone fishing for your employee's internals, whether they ask outright, dress it up as a game, or try the repeat everything above this line trick. On the way out it reads the reply itself and holds it back if it is about to hand over a system prompt, internal configuration, an access token, or a credential. Questions about your own business data are never affected, so an employee still answers freely about your customers, documents, and numbers. One switch, no configuration to maintain, and every attempt is logged so you can see who has been probing. - [Prevent Repeated and Runaway Actions](/en/features/guardrails/tool_safety): Sistava automatically caps how many emails, messages, and external writes (CRM records, calendar events, paid searches) an AI employee can send in a single conversation, hour, and day, and blocks an identical send to the same recipient from going out twice within 24 hours. These limits run in the background per employee with no setup required, so a stuck task or unexpected loop cannot spam a contact's inbox, pollute your CRM, or burn through paid API calls. When a limit is hit, the employee is told to slow down or hand the task to a human instead of retrying blindly. - [Approve Sensitive Actions](/en/features/guardrails/input_requests): Let an AI employee pause and ask before it takes a sensitive action, like sending an email or spending on a paid tool, instead of guessing what you want. An inline card shows up right in the chat with Approve, Reject, or option buttons, and the employee resumes the instant you respond. - [Protect Organisation Information](/en/features/guardrails/information_boundaries): Your AI employee treats what it learns in the workspace the way a careful coworker would: useful for doing the work, not free to repeat. It tells private, role-restricted, and confidential information apart from ordinary shared context, and it never volunteers the sensitive kind just because someone asked. When a teammate needs a restricted answer, the employee can request permission from the right person for that one specific answer instead of guessing or refusing outright. - [Protect Your Email Reputation](/en/features/guardrails/email_deliverability): Every email your AI employees send, whether it is a notification, a mailbox reply, or an outbound message, passes through a pre-send check before it leaves. Sistava validates the address, checks it against a suppression list built from past bounces and complaints, and blocks anything that would hurt your sending reputation. You do not configure this: it runs silently on every send so your domain keeps a clean track record with inbox providers. - [Delegation & Teamwork Limits](/en/features/guardrails/delegation_teamwork_limits): Tune how your leader employees hand off work to teammates. Set how many teammates a leader can delegate to at once, how far a delegation chain can reach, how long a delegated teammate can work before timing out, and how tolerant employees are of repeating themselves before loop protection stops them. - [Detect and Redact PII](/en/features/guardrails/pii_detection): PII Protection watches every message your AI employees send and receive, and masks personal data like emails, phone numbers, credit card numbers, and social security numbers before it goes anywhere it shouldn't. You choose exactly which data types to catch. It runs on every employee across your company the moment you turn it on, with no per-employee setup. - [Company-Wide Policies](/en/features/guardrails/company_policies): Company Policies let you set organization-wide safety rules that apply to every AI employee at once: block prompt injection attempts, filter harmful output, redact personal information, stop internal details from leaking, and restrict which topics employees can discuss. Turn each policy on with one toggle from your company dashboard, and it takes effect immediately across your whole team. ## Explore - [Every feature](/en/features) - [Hire an AI employee](/en/market) - [Pricing](/en/pricing)