> For the complete documentation index, see [llms.txt](https://docs.glbnxt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.glbnxt.com/platform/security-and-compliance/guardrails.md). # Guardrails A guardrail is an automatic check that sits between a person (or an application) and an AI model. It looks at what goes into the model, what comes out, or both, and acts when it finds something that should not pass. On GLBNXT Platform, guardrails check every request your organisation sends to a model. By default, personal details, identity numbers, payment and bank details, and credentials are masked before the request leaves the platform. {% hint style="info" %} This page explains the guardrails the platform applies to every model request. To add your own checks inside an n8n workflow, see [Using Guardrails in n8n](https://docs.glbnxt.com/tutorials/guides/n8n/guardrails-in-n8n). {% endhint %} ### Why guardrails matter People paste real data into AI requests. A customer email still carries its signature. A support ticket contains a phone number. A log file includes an access key. Most of it ends up there by accident, while someone is simply trying to get work done. Once that data reaches a model, you cannot call it back. That has consequences: * **Personal data.** Under the GDPR, sending personal data to a model is processing, and it needs a lawful basis and appropriate care. Data minimisation means you do not send what the task does not need. * **Credentials.** An access key or token in a request can leak through logs or through the model's answers. * **Trust.** Your users and customers expect their details to stay where they shared them. A guardrail is a safety net. It catches the common shapes of sensitive data, consistently and on every request. It does not replace a clear AI policy or user training, and it does not catch every possible form of sensitive data. ### How guardrails work Guardrails differ on three points: where they check, what they look for, and what they do when they find something. **Where they check** * **On the input**: the request is checked before it reaches the model. * **On the output**: the model's answer is checked before it reaches the user. Some products check both. **What they look for** Most guardrails look for **patterns**: recognisable shapes such as an email address, an IBAN or a card number. Others use keyword lists, for example to detect harmful content, or a separate classifier model. **What they do when something matches** * **Mask**: replace the value with a placeholder and let the request continue. The model still understands that there was an email address in the text, without seeing the address itself. * **Block**: refuse the whole request. * **Log or flag**: let the request pass and record that something matched. **The trade-off: misses and false alarms** No pattern is perfect. A value written in an unusual format can slip through. That is a **false negative**. A harmless value that happens to look like a protected one gets caught. That is a **false positive**: an order number with the shape of a phone number, for example. Context helps to reduce false positives. Some patterns only match when a keyword is nearby, such as a citizen service number next to the word "BSN". This keeps unrelated nine-digit numbers out of the net, but it also means the number is not recognised when the keyword is missing. ### How GLBNXT applies guardrails GLBNXT checks **every request** your organisation sends to a model through the platform, **before it leaves the platform**. The check runs on GLBNXT's own servers and does not store your text. * **Input only.** GLBNXT checks the request. Answers from the model are not checked. * **Mask, never block.** A matched value is replaced by a placeholder such as `[EMAIL_REDACTED]`. The rest of the request reaches the model unchanged, so your work continues. * **Eight protections in three groups, all on by default:** * **Personal details**: email addresses and phone numbers. * **Identity and tax numbers**: national ID numbers, passport numbers and VAT numbers. * **Finances and credentials**: payment cards, bank accounts and credentials such as access keys and tokens. We recommend keeping this group on. * **Controlled per organisation.** An administrator can switch individual protections off or on for the whole organisation. Every change is recorded in the [audit log](https://docs.glbnxt.com/configure-glbnxt/platform-configuration/compliance/audit-logs). * **On by default.** The protections run for every organisation, whether or not anyone opens the Guardrails page. They stay on until an administrator switches one off. To see exactly what is masked, test your own text and manage the protections, see the [Guardrails user guide](https://docs.glbnxt.com/configure-glbnxt/ai-platform/guardrails). ### Related pages * [Security architecture](/platform/security-and-compliance/security-architecture.md) * [Audit logs & Query history](/platform/security-and-compliance/audit-logs-and-query-history.md) * [Guardrails user guide](https://docs.glbnxt.com/configure-glbnxt/ai-platform/guardrails) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.glbnxt.com/platform/security-and-compliance/guardrails.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.