# Control What Employees Discuss 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. Topic Control is one of five company-wide safety policies on your Policies tab, alongside Input Safety, Output Safety, PII Protection, and Data Leakage Prevention. Turn it on and add a list of subjects your AI employees must not discuss: politics, competitor pricing, medical advice, legal advice, or anything else outside your company's comfort zone. The moment you save the list, every employee across every team respects it on their next message. There is no per-employee or per-team override; the block list is one shared list for the whole organization. Add topics as free-text tags on the Topic Control card, no fixed limit on how many you list. Behind each topic, the platform builds a small set of example phrasings ('tell me about X', 'what do you think about X', 'let's discuss X', 'what is X') and asks a separate, lightweight guardrail model to recognize when an incoming message matches that intent, not just the literal words. Someone rewording the question, asking around it, or phrasing it as a hypothetical still gets caught, because the check works on meaning, not a keyword blocklist. When it matches, the employee returns one scripted line: "I'm not able to discuss {topic}. Let me help you with something within my area of expertise." The wording is fixed by the platform, not left to the employee's judgement, so the refusal reads the same way every time regardless of how the request was phrased. The difference from writing "never discuss politics" into an employee's persona is enforcement layer: a persona instruction is a request the underlying model can still be talked out of under enough pressure, while Topic Control runs as a separate check before the employee's own reasoning ever starts, on a different model that only has one job. It also differs from the other four Policies it sits next to. Data Leakage Prevention blocks questions about your system prompt, internal configuration, or setup details, regardless of subject matter. Input Safety blocks prompt injection and jailbreak attempts, regardless of topic. Topic Control is the only one of the five that lets you name actual subject matter and have it refused by name, which is what makes it the right tool for keeping a support or sales employee inside its lane rather than general jailbreak resistance. ## What counts as a match Each blocked topic you add becomes its own recognition rule built from a handful of example phrasings of that topic. The check runs on the incoming message before the employee starts working, using the same lightweight guardrail model used for Input Safety and Output Safety rather than the employee's main model, so it adds negligible latency and no extra credit cost on top of what guardrails already use. Because the match is intent-based rather than a literal string search, a topic like "competitor pricing" catches variations like "what does the other guy charge" as well as the exact phrase. ## An enabled policy with no topics does nothing Toggling Topic Control on by itself has no effect. The check only runs against the topics you have actually added to the blocked list; an empty list means every message passes through unfiltered by this policy, silently. There is no default blocked-topic list and no starter set, since "off-limits" is entirely specific to your business. If you turn the policy on and nothing appears to be blocked, the first thing to check is whether the list on the Topic Control card is actually populated. ## Company-wide, not per-employee Every one of the five Policies, Topic Control included, applies to all employees across all teams at once. There is no way to give one employee a different blocked-topic list than another from this screen. If a single employee needs a narrower instruction, for example a support employee that should stay off pricing negotiation while a sales employee is allowed to discuss it, that distinction belongs in that employee's Duties, which are per-employee behavioral instructions, not in Topic Control, which is organization-wide. ## How It Works **Each exchange is checked against your allowed and blocked topics, per employee, on every channel.** You define the rails per employee: an allow list for the subjects it exists to handle, a block list for subjects that are off limits. The guardrail evaluates each exchange against those lists and steers or stops the conversation when a line is crossed. Enforcement lives at the guardrail layer, not inside the prompt, so the boundary holds as a conversation gets longer or more adversarial. Crossed-boundary attempts are logged, which both proves the rail is working and surfaces topics your customers keep asking about. ## Use Cases ### Keep support out of legal and medical territory Block "medical advice" and "legal advice" so a customer support employee redirects those questions to a human instead of guessing at something that carries real liability. ### Stop a sales employee from badmouthing competitors Block competitor names or "competitor comparisons" so a sales employee sticks to your product's strengths instead of getting drawn into a comparison it might get wrong. ### Keep a public-facing bot off politics and controversy Block "politics" and similar subjects so a customer-facing employee stays neutral even when a visitor deliberately tries to steer the conversation off-topic. ### Protect an internal employee from scope creep Block subjects outside an employee's job, like an HR employee fielding engineering questions, so it stays focused on what it was hired to do instead of improvising outside its lane. ## Comparison | Before | After | |---|---| | Prompts ask the AI to stay on topic and hope. | Topic boundaries are enforced as policy on every message. | | A persistent user can steer the agent anywhere. | The rail holds no matter how long the chat runs. | | One global setting compromises every employee. | Each employee gets rails matched to its role. | | Off-topic detours get screenshotted and shared. | The employee redirects and the attempt is logged. | ## FAQ ### Does Topic Control catch a rephrased or roundabout question, or only the exact topic name? It catches rephrasings. Each blocked topic is matched by intent using a set of example phrasings and a dedicated guardrail model, not a literal keyword search, so asking about a blocked subject a different way still gets refused. ### What does an employee say when it hits a blocked topic? A fixed line: "I'm not able to discuss {topic}. Let me help you with something within my area of expertise." The exact wording is set by the platform for every blocked topic, so the refusal is consistent no matter which topic was triggered or how the question was asked. ### I turned Topic Control on but nothing is being blocked. Why? Toggling the policy on does not block anything by itself. Check that you have actually added topics to the blocked list on the Topic Control card; an enabled policy with an empty list lets every message through. ### Can I give one employee a different blocked-topic list than another? Not from Topic Control. It is company-wide: the same blocked list applies to every employee on every team. For a rule specific to one employee, use that employee's Duties instead. ## Where Control What Employees Discuss fits Control What Employees Discuss 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: Control What Employees Discuss](/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. - [Protect Against Prompt Injection](/en/features/guardrails/guardrail_input_safety): 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. - [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. - [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)