Scanning Policy: Protected Domains and Blocked Capabilities

Overview

Guard enforces two complementary policies before security jobs run: a code-level static deny list keyed off scan targets, and a configurable per-account (and global) list of blocked capability names. Together they prevent unwanted scanning against sensitive namespaces and let administrators turn off specific scanners for particular tenants.

Static domain deny list

At enqueue time, targets are evaluated against a static list of regular expressions maintained in the compute layer. If a job’s target matches a blocked pattern for that user context, the job is treated as denied before it enters the execution queue.

Patterns cover third-party and partner domains that must not be hit by automated scanning (for example historical Barclays and Nielsen property namespaces, ZoomInfo, and similar), as well as Praetorian-owned zones (for example praetorian.com) so customer-driven automation does not scan Praetorian infrastructure by default.

Demo and training accounts defined in code may receive narrow exemptions (for example for Praetorian-owned patterns only) so demonstrations can run without weakening protections for production tenants.

Exact patterns evolve with abuse reports and contractual requirements; treat this article as describing mechanism and intent, not an exhaustive domain inventory.

Per-account and global blocked capabilities

Administrators can configure blocked_capabilities as a JSON list of capability names (exact string matches) in:

• Tenant-scoped settings — applies to jobs for that account only.

• Global settings — merged into every account’s effective list at runtime.

During enqueue, if a job’s capability appears in the merged list, the platform blocks the job and emits a warning log. This supports per-tenant least privilege (for example disabling port scanning or nuclei for a customer contract) without code changes.

Relationship to AI guardrails

Curated domain deny lists are also described from an AI operational perspective in AI Operational Guardrails. The enqueue-time checks apply regardless of whether a human or the AI assistant requested the work, so policy is consistent across interfaces.