docs: add Enterprise prompt-injection screening page

[claude]

Requested by Micah Stairs · Slack thread

Before

Nothing on docs.firecrawl.dev describes screening scraped content for prompt-injection payloads. Questions about it get pointed at Lockdown Mode, which does something else entirely.

After

A new Enterprise page, features/prompt-injection-screening, that says three things:

1. The problem. A scraped page is untrusted input. Text on the page can carry instructions aimed at whatever model reads it downstream. Hidden text is the concrete case: white-on-white, zero font size, off-screen positioning, and comparable tricks. A human viewing the page never sees them; a markdown or text conversion preserves them.
2. What it is not. It is not Lockdown Mode. Lockdown serves from Firecrawl's index and cache without an outbound request to the target, which is an egress and compliance control. It does not inspect content, and when a request does not set an age limit, the limit under Lockdown is much longer, so a served page can be older. The page links to the Lockdown page and states the difference directly.
3. The behavior, conceptually. Content is classified and suspected injection is flagged. Screening is selected per request, and Firecrawl can force it on for every request on an account when the customer asks. Content is not withheld by default.

How

• Added features/prompt-injection-screening.mdx, matching the frontmatter, heading style, Note-callout enterprise-gate convention, and voice of the existing features/threat-protection.mdx and features/siem.mdx pages.
• Registered the page in docs.json in the Enterprise nav group, next to Threat Protection and SIEM. Both English Enterprise groups (the visible one and the hidden duplicate) were updated. No localized nav entries and no localized files were touched, per CLAUDE.md.

Review edits applied

Four changes requested by Micah Stairs, in commit ea93eda:

1. No em dashes. The page's one em dash is gone, rewritten as two short sentences rather than swapped for a hyphen. Zero em dashes remain.
2. No meta-commentary about readers. "Teams confuse these two features." is removed, along with "than you expect" and "You can care about both." The substantive Lockdown Mode distinction is kept.
3. House Enterprise-gating pattern. The ad-hoc gate sentence and the soft sales line ("Talk to your account team about how the feature fits your workloads.") are replaced with the Note wording used verbatim by features/threat-protection.mdx and features/siem.mdx: "Prompt injection screening is an enterprise feature and is gated per organization. Contact your Firecrawl account team to have it enabled for your account." Placement matches those pages: after the intro prose, before the first heading. The separate ## Availability section, which held the invented availability formula, is gone.
4. Corrected the availability behavior. The page previously said policy is configurable per account and that the account team sets it, and that the safe default is to withhold. Both were wrong. The page now says screening is selected per request, that Firecrawl can force it on for every request on an account on request, and that content is not withheld by default. The contradicting "safe default is to withhold" bullet was fixed in the same pass, so nothing on the page still implies screening withholds or is on by default.

Still no parameter, field, or code sample is named anywhere on the page.

Please read before merging

• This documents an Enterprise feature that is NOT yet wired into API parameters. The requester was explicit about this.
• No API surface is described. The page contains no request parameter, no field name, no response shape, and no code sample. There is nothing on it a reader could paste into an API call. That is deliberate, not an omission to fill in during review.
• No date or roadmap commitment appears anywhere on the page.
• The underlying screener exists today only as an internal component, an accepted ADR covering Firecrawl's own agents. So this page describes intent, not a shipped API.
• The availability wording no longer needs a bespoke decision: it reuses the existing Threat Protection and SIEM sentence verbatim.

Also worth a second opinion: whether this belongs on enterprise.mdx's feature list too. I left it off, since Threat Protection and SIEM are not listed there either.

Validation

• docs.json parses as valid JSON. The review edits did not modify it.
• The one internal link on the new page, /features/lockdown, resolves to features/lockdown.mdx.
• Zero em dashes, and no other Unicode dash characters, remain on the page.
• No "Safe Mode" mention, no dates, and no accuracy or latency claims.
• Prettier was not run as a write step. The repo baseline is not Prettier-clean (docs.json, features/lockdown.mdx, and features/threat-protection.mdx all fail prettier --check on unmodified main), so a repo-wide reformat would have buried this change in unrelated churn. The review edits follow the file's existing style.
• No API code, types, or request parameters were changed. This repo is docs-only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MGRyumQaNvjFxq8qFjm3o1

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
firecrawl	🟢 Ready	View Preview	Aug 21, 2026, 6:58 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.