The challenge
When your agent opens a session replay to diagnose a bug or trace a user journey, it reads the same event stream the recorder captured. That stream can contain raw input values from every text field a user touched. Without protection, sensitive data flows directly into your agent’s context window — and potentially into logs, traces, or model inputs downstream. The risk is not hypothetical. A single session touching a checkout flow or an account settings page can contain payment card numbers, passwords, and personal identifiers all in the same recording.Baseline protection
Subtext masks form inputs from the moment you install. No configuration required. Field values — passwords, credit card numbers, anything typed into an<input>, <textarea>, or <select> — are redacted in the browser before the data ever leaves the page. Your agent never sees those values, because they are never recorded.
This baseline masking is automatic and cannot be accidentally disabled through the privacy tools. It applies to all sessions from your very first recording.
Agent-driven governance
The privacy tools give your agent a complete governance loop. Instead of auditing sessions yourself and hand-writing CSS selectors, you point your agent at a real session and let it do the scan. The agent identifies what looks like PII, proposes specific masking rules, creates those rules in a safe preview scope, and — once you’ve confirmed they work — promotes them to cover every future session.The governance workflow
1
Scan — propose rules from a real session
Run
privacy-propose against a session ID. The agent inspects the session’s event stream, identifies elements that appear to contain PII, and returns a set of suggested CSS selectors along with a rationale for each. This is a dry-run: nothing is written or changed.2
Create — persist rules in preview scope
Pass the selectors you want to adopt to
privacy-create. Rules created here are preview rules — they apply only to sessions opened in preview mode, not to your full production capture. This lets you verify that the selectors mask the right elements without affecting live data collection.3
List — inspect active rules
Call
privacy-list at any point to see all active rules across both preview and production scopes. Use this to audit what is already masked, spot duplicates, and confirm that a newly created rule appears before promoting it.4
Promote — go live across all sessions
When a preview rule is confirmed correct, run
privacy-promote with the rule’s ID. The rule immediately escalates to production scope and begins applying to every captured session — past recordings are unaffected, but all new sessions will mask the targeted elements.5
Delete — remove preview rules you no longer need
Use
privacy-delete to remove preview rules by ID. Only preview rules can be deleted through the agent. Live rules are intentionally protected — removing a production masking rule could expose PII in future recordings, so that action requires a deliberate manual step outside the agent tooling.Preview vs. production rules
The distinction between preview and production scope is the central safety mechanism in Subtext’s privacy model. Preview rules let you iterate freely — create, test, and discard candidate selectors without any risk of breaking your production masking coverage or accidentally unmasking data in live sessions. Production rules, by contrast, are durable and protected. Once a rule is live, the agent cannot delete it. This asymmetry is intentional: it ensures that the agent can autonomously propose and validate privacy improvements, while a human retains final authority over what gets removed from production coverage.See the Tools Reference for full parameter documentation and example usage for each privacy tool.