Security
The Security section holds the settings that decide what your assistant will discuss, what it may see of your customers’ data, and which tools a chat session is offered. Open it from Security in the sidebar. The guardrails check every message an end customer sends before the AI answers, data masking hides parts of sensitive values in your API’s responses, and tool policies let you define and simulate which tools a set of policy keys grants.
Each control acts at a different moment of a chat turn, so they complement each other rather than overlap. None of them replaces the permission checks in your own API: StrikeUp calls your API on the customer’s behalf, and your API still decides what that customer may read or change.
Pages in this section
Section titled “Pages in this section”| Page | What it is for | Where it acts |
|---|---|---|
| Guardrails | Write the company policy that decides which messages are allowed, test messages against it, and set the reply customers see when a message is blocked | On every incoming end-customer message, before the AI answers |
| Data masking | Create masking rules for fields in your API responses, activate the rules StrikeUp suggests, and test rules on sample JSON | On every successful tool response, before the AI and the tool-run log see it |
| Tool Policies | Name sets of tools under a policy key | When a session’s tool list is built, if the session carries policy keys |
| Tool Access Simulation | See which tools a widget offers for a choice of policies, or compare two choices side by side | Nowhere live; it only simulates |
Tool Access Simulation has no sidebar entry of its own. Open it with the button of the same name at the top of SecurityTool Policies.
What you can do here
Section titled “What you can do here”- Decide what the assistant will talk about. Describe your business in the company policy, or let StrikeUp draft one from your website address and toolkits. Guardrails.
- Check a message before your customers send it. The test box on the guardrails page shows the verdict, the reason and every violation, and nothing is recorded. Guardrails.
- Hide card numbers, IBANs and other personal data from the AI. A masking rule keeps the first and last characters of a field and replaces the rest. Data masking.
- Review the masking rules StrikeUp suggests. When a toolkit is generated, StrikeUp proposes rules for fields that look sensitive; they mask nothing until you activate them. Data masking.
- Group tools under a policy key and simulate the result. See exactly which tools a widget offers for one set of keys, or compare two sets. Plan and simulate tool policies.
- Prepare for go-live. Work through guardrails, masking, tool approvals, two-factor authentication and budgets in a safe order. Secure your assistant before go-live.
How the controls fit together
Section titled “How the controls fit together”A chat turn passes through the controls in this order:
| Order | What happens | Control |
|---|---|---|
| 1 | The end customer’s message arrives | — |
| 2 | The message is allowed or blocked. A blocked message gets your blocked reply, and the AI never sees it | Guardrails |
| 3 | StrikeUp checks your AI budgets with a hard limit | Budgets & limits |
| 4 | The session’s tool list is built from the widget’s toolkits and their active tools, narrowed by policy keys if the session carries any | Tool policies |
| 5 | A tool that needs approval waits for the customer to approve it | Toolkits |
| 6 | Your API answers, and masking rules are applied to the response before the AI reads it and before it is written to the tool-run log | Data masking |
Concepts to know
Section titled “Concepts to know”Guardrails decide allow or block, nothing else
Section titled “Guardrails decide allow or block, nothing else”The guardrails check returns one of two verdicts. It cannot make the assistant answer with a sentence of your choosing: a blocked customer always sees the one blocked reply you set on the guardrails page, or the platform default. Every blocked message is listed on AnalyticsViolations.
Masking is one-way
Section titled “Masking is one-way”A masking rule changes the value in the API response itself. The AI, the chat answer and the tool-run log all work with the masked value, and StrikeUp keeps no copy of the original. Masking applies only to your API’s responses, not to what customers type in the chat.
Tool policies cover only customers your backend signs in
Section titled “Tool policies cover only customers your backend signs in”A tool policy is a name, a key and a set of tools. A session that carries policy keys is offered only the tools mapped to those keys; a session without keys is offered every active tool of the widget’s toolkits. Only your own backend gives a customer policy keys, in the one-time login ticket it signs the customer in with; the page that embeds the widget cannot set or change them. Customers who sign in any other way carry no keys and are offered every active tool. To keep a tool out of their reach, switch it off on the Toolkits page, require approval for it, and let your API refuse what the customer may not do. Keep doing that for every customer, as a second line of defence.
Availability
Section titled “Availability”Every workspace has the Security section; no plan or feature switch hides it. Every signed-in member can open the pages and use the guardrails and masking test boxes. Saving, creating, editing and deleting need the Admin role; other roles see the buttons, but the change is refused with Request failed and “This action requires the Admin role.” Tool Access Simulation also needs the Admin role, although it changes nothing.