Remove active content
A model’s reply is text, and text you render can contain things you’d rather not run. Remove Active Content — the last switch in the policy wizard’s Content Policy step — takes the executable parts out of a reply before it reaches whatever displays it.
What it removes
| Removed | Why |
|---|---|
<script> and <style> | Executable and injectable |
<iframe>, <object>, <embed>, <svg> | Can load or run remote content |
<form> | Can submit user input somewhere unexpected |
<base>, <meta>, <link> | Can rewrite where other content resolves from |
on* event handlers, e.g. onclick= | Run on interaction |
javascript:, vbscript:, data:text/html, data:image/svg+xml links | Execute when followed |
What it keeps
Ordinary formatting survives untouched — <b>, <table>, safe <a href> links, data:image/png images, and all markdown.
Code blocks are never touched. Fenced blocks and inline code spans pass through exactly as written. Ask an agent for an XSS example or a React component and the answer is full of <script> and onClick inside code fences — stripping those would destroy the answer you asked for. The rule applies to prose, not to code.
When to turn it on
- The agent’s replies are rendered as HTML anywhere — a chat widget, an embedded assistant, a generated page.
- The agent summarises content it fetched from the web or from user uploads, where the source isn’t yours.
- You want a second line of defence behind whatever sanitising your own front end does.
If replies are only ever shown as plain text, this changes nothing and can stay off.
A behaviour worth knowing
Removal works line by line, which is what keeps code-fence tracking reliable while a reply streams in.
The practical consequence: an element that opens and closes on one line is removed whole, contents and all. An element spread across several lines has its tags removed while the inner text remains as plain text.
So a multi-line <form> comes back as its labels and button text without the form. A multi-line <script> comes back as inert text — the tags are gone, so there’s nothing left to execute, but the JavaScript is still visible as words.
Nothing executable survives either way. The difference is tidiness, not safety.
Where it applies
On the model’s reply, on both streaming and non-streaming responses. It doesn’t touch the prompt going out — for that, see PII detection and blocked content.
Common issues
- Leftover text where a script was — expected for multi-line elements. See above.
- A code example lost its formatting — that shouldn’t happen; code regions are exempt. Check the model actually fenced the code rather than emitting bare HTML in prose.
- A link stopped working —
javascript:anddata:links are removed by design. Ordinaryhttp/httpslinks are kept.
Next
- Response cache — the Advanced step.