Security & Privacy

Lexega is an offline-by-default CLI you run in your own environment. This page documents data flow boundaries and what changes when you enable optional integrations.

Defaults (Offline)

• No telemetry to Lexega-controlled services.
• Core formatting/risk analysis runs locally on SQL text.
• Output is written only to destinations you configure (stdout/files/CI artifacts/object storage).

Optional Integrations (Outbound)

Lexega can be configured to talk to external systems. When you enable these options, data may leave the machine/network where the CLI runs.

Optional: Catalog Integration

The lexega-sql catalog command connects to Snowflake using your credentials to fetch metadata.

Metadata Surfaces

Catalog reads metadata from Snowflake surfaces such as INFORMATION_SCHEMA and SNOWFLAKE.ACCOUNT_USAGE, plus some SHOW commands. If you enable --include-grants, metadata can include usernames/user-role assignments.

What It Does NOT Access

• ❌ Your actual table data — never runs SELECT on your tables
• ❌ Business-query results — catalog queries are limited to metadata surfaces
• ❌ User credentials — uses your existing Snowflake authentication

Security Notes

• Catalog integration is opt-in — if you don't use it, the CLI never connects to Snowflake
• All queries are read-only metadata — no write operations
• ACCOUNT_USAGE queries may fail without appropriate privileges — the catalog tool handles this gracefully
• The catalog tool does not transmit data to Lexega or third-party telemetry endpoints; output is written to the destination you configure (stdout, local files, or cloud storage)

Data Handling

Input Processing

1. SQL file read into memory
2. Analyzed in-process
3. Results written to stdout or a destination you configure
4. Memory released—no persistent state

No Data Retention

• Stateless operation: Each CLI invocation is independent
• No caching: Queries are not cached between runs
• No logging: No query logs written to disk (unless you configure output)
• No temporary files: Analysis performed entirely in memory

Compliance Considerations

GDPR

• Typically no personal data: Core analysis operates on SQL text, not the data returned by queries
• No data transfer to Lexega: No telemetry or upload to Lexega-controlled services
• DPA depends on configuration: If you enable options that collect user identifiers (for example, grant graph) or transmit reports to third parties (for example, PR comments), consult your legal team/DPO

HIPAA

• No PHI exposure: Lexega does not access table data or the results of your business queries
• BAA depends on your program: Whether you need a BAA is a decision for your compliance/legal team based on how you deploy and what metadata you collect/store

Auditability

• Audit trail: Decision records provide immutable evidence of policy enforcement
• Deterministic: Same input always produces same output (reproducible)
• No Lexega telemetry by default: Optional integrations (Snowflake catalog / PR comments) may transmit data to systems you configure

PCI-DSS

• No cardholder data: Lexega operates on SQL text, not data
• Scope depends on deployment: PCI scope is determined by where you run Lexega and where you store outputs
• Access controls: Runs under your CI/CD identity and permissions

Vulnerability Disclosure

If you discover a security vulnerability in Lexega:

1. Email: security@lexega.com
2. Include: Detailed description, reproduction steps, impact assessment
3. Response: We'll do our best to acknowledge quickly
4. Disclosure: Coordinated disclosure after fix is available

Security Questionnaire

Some organizations require security questionnaires. Key answers:

---

Questions? Contact security@lexega.com