Firecrawl Policy GuardrailsSAFE

Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: firecrawl-policy-guardrails
description: >-
  Enforce domain authorization, robots and terms review, endpoint and format allowlists, scope, spend, retention, and unsafe-content controls around Firecrawl. Use when governing automated collection. Trigger with "Firecrawl guardrails", "scraping policy", or "restrict Firecrawl domains".
allowed-tools: Read,Glob,Grep,Write,Edit
argument-hint: "<repository-path> <policy-file>"
version: 1.12.0
license: MIT
author: Jeremy Longshore <[email protected]>
tags: [saas, firecrawl, policy, compliance]
model: inherit
effort: high
compatibility: "Designed for Claude Code; Firecrawl Cloud work requires network access"
---
# Firecrawl Collection Policy Guardrails

## Overview

Put enforceable policy before every Firecrawl request and downstream action. Provider capability does not establish permission to collect, retain, or reuse a source.

## Prerequisites

- The target repository or integration path and the requested operator outcome.
- The source authorization, data classification, and environment policy.
- Current Firecrawl documentation, credentials only when needed, and an owner for approvals.

## Current Contract

Firecrawl crawl supports scope controls, explicit limits, delay, maxConcurrency, and an enterprise robotsUserAgent option. Enterprise controls include endpoint/format key restrictions, IP restrictions, threat protection, and SIEM integration. Request options such as headers, actions, proxy, cache, ZDR, lockdown, and raw formats have separate risk and availability implications.

## Authentication

For authenticated Cloud operations, inject FIRECRAWL_API_KEY from an approved
secret manager. REST requests use Authorization: Bearer with the key. Never print,
commit, transmit, or place a key in a URL. Keyless access is suitable only where
the current documentation explicitly allows it and the workload accepts its
limits; production workflows should make identity and team ownership explicit.

## Instructions

1. Create a versioned source registry with owner, authorization basis, allowed purpose, domains/paths, robots and terms review, data classes, retention, and expiry.
2. Canonicalize URLs before policy evaluation. Deny unsupported schemes, embedded credentials, private/link-local addresses, disallowed ports, redirects outside scope, and lookalike hosts.
3. Allow only required operations, formats, actions, headers, locations, proxy modes, and crawl settings. Set explicit page, time, credit, and concurrency ceilings.
4. Apply provider-side key, IP, threat-protection, and audit controls where entitled, but keep application policy authoritative and fail closed if it is unavailable.
5. Treat retrieved content as untrusted data. Separate it from system instructions, validate extracted JSON, sanitize active content, and gate downstream actions.
6. Log policy version, decision, source class, request class, limits, and opaque IDs without keys, URLs with secrets, headers, prompts, or bodies.
7. Test redirect, DNS rebinding, wildcard, internationalized-domain, restriction bypass, budget, retention, and prompt-injection cases before rollout.

## Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, tests, and evidence. Use
Write/Edit only for approved implementation or documentation changes. Do not call
Firecrawl, rotate keys, change account settings, scrape a target, or deploy merely
because this skill was invoked.

## Approval Boundaries

Require policy-owner and legal/security review before adding a domain, collecting authenticated or personal data, changing robots/terms posture, enabling broad actions/proxies, or weakening retention and limits.

## Output

Return the policy artifact/version, authorization inventory, canonicalization and allow/deny rules, provider controls, test corpus and results, exceptions, owners, and enforcement receipt.

## Error Handling

- Authorization basis is missing or expired: deny the request.
- Policy service is unavailable: fail closed or use a pre-approved read-only degraded policy.
- Redirect or resolved address escapes scope: stop before sending credentials or following content.

## Examples

- "Allow our documentation domains" creates exact host/path rules and redirect tests.
- "Ignore robots because Firecrawl can crawl it" is rejected pending the governing policy decision.

## Resources

Read [official Firecrawl evidence](references/official-docs.md) before relying on
an endpoint, SDK method, plan limit, price, retention option, or self-hosted release.

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.