Content Policies and Guardrails

This Botlit concept treats guardrails as a first-class object in the workspace rather than a setting buried inside each agent. The illustration opens a single content policy, in the sample a member data protection policy in a health-sector workspace, reached from the Policies section. The header carries the policy name, a type badge marking it as a content policy, an active state, a scope badge showing it applies workspace-wide, and controls to edit or deactivate it.

The problem is that unsafe behavior arrives from both directions. A user can paste sensitive identifiers into a chat, and an agent can reproduce them in a reply, and neither is caught by tuning instructions alone. The design is built to act on both sides of a turn, as the enforcement feed later shows. In the configuration card, a PII detection checkbox, shown switched on, is described as blocking social security number, credit card and email shapes. A blocked keywords field holds terms the workspace does not want passing through, in the sample things like a diagnosis code, a member identifier and a policy number. A separate field holds regular expressions for identifier shapes that keywords cannot describe.

Because guardrails rarely act alone, a card beneath lists the other policies active in the same workspace with their type, their limit and their state, in the sample a rate limit expressed as requests per minute and a daily token budget. That gives a reviewer the full set of constraints on one page instead of scattered across agents.

The right side answers the question every governance feature has to answer: is it doing anything. A recent enforcement feed lists timestamped events from this policy and the other limits in force, most of them naming the agent involved, covering an input blocked on a personal-identifier match, an output blocked where a keyword was replaced by a refusal, a rate limit tripped by a burst of runs, and a daily token budget overrun. A small chat bubble at the bottom shows the reader what the blocked output looks like from the other end: a short, plain refusal telling the person the response was blocked by the workspace content policy. Together the page connects policy authoring, the other limits in force, and evidence of enforcement, and the token counts a budget measures are the same figures the execution ledger concept records for each run.