Pheonix Shield

The product is the evidence. The evidence has to hold up.

Pheonix Shield is built to produce records that are defensible — to regulators, to courts, to your own internal audit team. Here is exactly how we do that, what controls we have in place, and how to verify our claims independently.

Evidence integrity

How a record is created and protected:

  • Page captured by a headless browser with the user-agent identified as Pheonix.
  • Full DOM snapshot taken post-JavaScript execution.
  • Full-page screenshot captured at desktop and mobile breakpoints.
  • SHA-256 content hash computed at the moment of capture — for tamper detection and chain-of-custody verification, not content deduplication.
  • Record written to append-only storage; subsequent agents verify the hash before reading.
  • Optional: external RFC-3161 timestamp from an independent timestamping authority.

What you can verify yourself:

  • Re-hash any retrieved record and compare to the stored hash.
  • Replay the agent pipeline against the original snapshot and verify identical output.
  • Audit the chain-of-custody log for every record in your account.

Determinism

Compliance determinations must be rule-based and reproducible. AI agents orchestrate capture and evidence compilation, but every finding traces to a deterministic match in our codified rule library. Pheonix achieves reproducibility through:

  • Version-pinned models for every agent
  • Versioned prompts, with semantic versioning visible per finding
  • Deterministic decoding parameters (temperature 0, fixed seeds where supported)
  • Cached intermediate artifacts let us replay and reproduce a specific evidence record without re-fetching the page. Each scheduled sweep independently re-evaluates the live page; caching is for reproducibility of a given record, not for skipping content from compliance review.

If a finding is ever questioned, the exact agent versions, prompt versions, and intermediate artifacts that produced it are all retrievable.

Information security

Certifications.

  • Annual third-party penetration testing
  • Continuous vulnerability scanning

Data handling.

  • Encryption at rest (AES-256) and in transit (TLS 1.3)
  • Customer data isolated per tenant
  • US-only data residency by default
  • No customer data used for model training

Access controls.

  • SSO via SAML 2.0 (Okta, Azure AD, Google Workspace)
  • Role-based access control with least-privilege defaults
  • Full administrative audit log
  • Session management and configurable timeouts

Subprocessors and dependencies

A live, dated list of every subprocessor with the data they handle and the contractual terms in place. Updated within 30 days of any change. Notification subscription available.

Responsible disclosure

We welcome reports from security researchers. Our disclosure program covers the production application, the public marketing site, and our customer-facing APIs. Out-of-scope items, response time targets, and safe-harbor language are documented in our disclosure policy.

Compliance with the laws we monitor

We are aware of the recursive irony: a compliance company collecting public dealer-website data needs to do so lawfully and ethically. Our position:

  • We respect robots.txt as a baseline.
  • We rate-limit per-domain to avoid disrupting normal site operations.
  • We identify our scanner in the user-agent string.
  • We capture only publicly accessible pages.
  • We do not bypass authentication, paywalls, or anti-bot measures.

Where regulatory monitoring activities require us to depart from these defaults, we document the exception, obtain authorization from the customer whose dealers are being monitored, and log the deviation.