Policy & Guardrails

Inside the ThinkStack runtime, on every request and every response. Five policy types are available: content filters, denied topics, word filters, sensitive information, and grounding. Each is set separately for requests and responses, except grounding, which checks responses against what the agent retrieved.

Yes, per entity type and per direction. More than 30 standard entity types are supported, plus custom patterns for identifiers only your organization uses. Each can be masked with a placeholder or can block the turn, and requests and responses are set separately, so a record number a user types can pass on the way in and still be masked on the way out.

Run real prompts through the draft policy. ThinkStack returns the verdict and every rule that fired, with its confidence, the action taken, and the text it matched, before the policy is published. Changes are staged as proposals you review before they take effect.

The message you wrote for that case, set separately for requests and responses. In agent conversations, the guardrail step also appears in the conversation, so it's clear a policy acted. Every change to the policy itself is kept in its version history.

Yes. A policy can be applied to a single agent or to every conversation in the workspace. Share it and each person gets their own copy that stays in step with yours, so a central rule doesn't have to be rebuilt per team. Every published policy is a version with history.

Yes, for denied topics. Set a denied topic to detect instead of block, and it reports what it found without refusing the turn, so you can see what it would catch before you enforce it. Content filters always block.

Three steps. Describe the rule and review the staged changes. Test it on real prompts before it goes live. Then publish a version and apply it to one agent or to every conversation in the workspace, with actions set per direction and per entity type.