Content Boundaries: What Your Agent Should Refuse, and How to Test It

Model providers build in broad safety behavior. That handles the general case and says nothing about your specific boundaries: what your agent should decline because of your policies, your regulatory position, or your product's scope.

Those boundaries are yours to define, and — like everything else about agent behavior — they need to be specified, enforced, and tested rather than assumed.

Four kinds of boundary you actually own

Scope. The agent handles billing, not legal advice. Not a safety question; a product one. An agent that improvises outside its scope produces answers nobody has reviewed and no team owns.

Regulatory. Financial, medical, legal, and employment contexts have rules about what can be said and by whom. An agent giving something that reads as regulated advice is a compliance problem regardless of accuracy.

Commitment. An agent shouldn't promise a delivery date it can't guarantee, quote a price outside the pricing engine, or accept liability. These get made accidentally, in helpful-sounding language, and they can be binding in ways nobody intended.

Tone and representation. It speaks as your organization. Speculating about competitors, commenting on internal matters, or being flippant about a serious situation is a boundary even when factually harmless.

Specify them as behaviors, not topics

A topic list — "don't discuss X" — is brittle, because the same topic can be fine or not depending on what's being done with it.

Specify the action:

❌ "Do not discuss refunds"
✅ "Do not state whether a specific refund will be approved.
    You may explain the refund policy and the process."

The second is testable, doesn't block legitimate help, and describes the actual risk — committing to an outcome rather than explaining a policy.

Enforce where it's enforceable

In code, when the boundary maps to an action. A commitment boundary is best enforced by the agent not having a tool that makes commitments, and by quotes coming from the pricing engine rather than from generated text. Structural enforcement beats instruction wherever the boundary is about doing rather than saying.

In the prompt, for genuinely linguistic boundaries. Tone, scope, refusing to characterize a competitor. State them as rules with the reason, since a rule with a rationale is applied more sensibly to unanticipated cases.

In an output check, for high-stakes phrasing. A cheap check on generated text for patterns that indicate a commitment — a specific date, a monetary figure not from a tool, guarantee language. ⚠️ Keep these narrow. Broad output filtering blocks legitimate answers and produces a frustrating product.

Give it somewhere to go

A boundary without an alternative produces an unhelpful refusal, which users experience as the product being broken.

Every boundary should pair with a route:

• Out of scope → "That's handled by the legal team; here's how to reach them."
• Can't commit → "I can't confirm a date, but I can show you the current status and typical timelines."
• Regulated → "I can explain how this works generally; for advice on your situation, here's who to contact."

✅ The refusal and the alternative should arrive together. A bare "I can't help with that" is the version that generates complaints.

Testing them

Same structure as any behavioral test — cases, assertions on behavior, run in CI:

• Direct requests for the boundary behavior.
• Indirect requests. "I'm not asking you to promise, but realistically when will it arrive?" This is how boundaries are actually crossed — a user who isn't attacking, just asking naturally.
• Escalating pressure. A user pushing across several turns. Boundaries that hold on turn one sometimes give way on turn four.
• Legitimate adjacent requests, where the correct behavior is to help. This half is essential: it catches over-refusal, which is the failure mode that follows every tightening.

boundary_holds:      24/24
legitimate_helped:   41/45   ← check the 4

🔍 Watch the refusal rate

In production, track how often the agent declines and sample those cases.

Rising refusal rate after a prompt change usually means over-tightening, and it's invisible in quality metrics because a refusal isn't a wrong answer. Sampling tells you whether declines are landing on the cases you intended — and in practice, over-refusal generates more user frustration than the boundary was preventing.

The takeaway

Your boundaries are scope, regulatory, commitment, and representation — none of which a model provider can define for you. Specify them as actions rather than topics, enforce structurally wherever the boundary is about doing rather than saying, always pair a refusal with a route, and test both halves: that the boundary holds under indirect and sustained pressure, and that adjacent legitimate requests still get help.