Navigation

Explore Kaiju

Start with a customer, prospect, account, client, or research list, then inspect how Kaiju supports each finding.

Already using Kaiju?

Continue to your Team.

Sign in

Trust resource

Define security requirements for each data flow.

Public web evidence and customer-provided company files are different data classes. Each should have explicit access, retention, processing, and delivery controls.

  • Data-flow review
  • Least-privilege access
  • Input and output separation
  • Controls matched to current availability

Example data-flow review

A concrete record, not an abstract claim

Input
Customer CSV with company, website, record ID, and owner
Processing
Company matching and public website research
Output
Updated CSV with supported findings and evidence links
Access
Named customer and Kaiju operators involved in the evaluation
Published
Jul 20, 2026
Last reviewed
Jul 20, 2026
Reviewed by
Kaiju research team
Applies to
Current public methodology and product direction

Data classes

Classify what moves through the product

Different records require different handling.

  1. 1Publicly observable website and network evidence
  2. 2Customer-provided company files and identifiers
  3. 3CRM fields, ownership context, and other operational columns
  4. 4Support, review, and correction communications

Access control

Minimize who can access customer files and results

Start with the narrowest practical access model.

  1. 1Small test sets before broader system access
  2. 2Only the fields required for the stated use
  3. 3Downloaded files before automated writes into another system
  4. 4Role-based access to customer outputs

Retention

Define retention and deletion

The input and generated output should have an explicit lifecycle.

  1. 1Uploaded-file retention
  2. 2Processed-result retention
  3. 3Logs and error records
  4. 4Deletion and correction requests

Current and future interfaces

Match controls to what is actually available

CSV delivery today and future programmatic interfaces carry different risks.

  1. 1Current upload and CSV download
  2. 2Future direct delivery and connector access
  3. 3Future API, webhook, and MCP authentication
  4. 4Future audit, credential-rotation, and write-control requirements

Continue the evaluation

Follow the next question behind the result.

Move from one trust concern to the methodology, product explanation, or limitation that helps your team decide whether the data is safe to use.

Test the method

Review the actual data flow before a larger rollout.

Bring the uploaded fields, delivery destination, access roles, retention expectations, and security requirements for the proposed use.