Guardrails
Filter sensitive information sent to models and what comes back from them.
Guardrails filter what travels between people and AI models, to keep answers aligned with the organization's policies.
They apply to the whole organization and don't depend on each Agent being configured correctly. It is the control that survives a badly written prompt.
The two directions
A guardrail acts at one of two points along the way:
- On the way in: blocks or masks sensitive information before it reaches the model. It is what keeps a CPF pasted into the chat from leaving the organization.
- On the way out: filters what the model returned, before showing it to the person.
The list on the screen shows the active set, with each rule's type.
Why in the organization and not in the Agent
An Agent is created by whoever builds in the workspace, with whatever prompt they want. Entrusting data protection to that prompt means trusting every person who creates an Agent.
Guardrails sit above that. A new Agent is born covered by the organization's rules without anyone having to remember to configure them.
Guardrails act on message content, not on what an MCP does. A tool that sends data to an external system doesn't go through this filter.
Day-to-day effect
Rules that are too tight cut legitimate answers, and the person in Chat sees the already-filtered result, with no explanation of what was removed.
When someone reports an incomplete answer with no apparent cause, this screen is one of the places to check, along with the state of the documents in the Collection.
Next steps
- Limit the connectors' reach in Knowledge domains.
- See what else is on this screen in Settings.