A product about environment risk should be careful about environment data.

The core principle: understand the reference, not just the raw value

The point of EnvPI is not to become a careless dumping ground for sensitive data. Its job is to build an operationally useful record of environment-linked assets: what exists, where it came from, what project or environment it belongs to, what vendor it appears tied to, and when an external issue might matter.

In practical terms, that means the system should be able to help a user long before it needs to behave like a traditional vault.

What EnvPI is designed to keep

• • Variable names and labels
• • Project and environment relationships
• • Vendor associations
• • Dependency relationships
• • Source provenance
• • Findings, recommendations, and resolution history
• • Handling metadata such as timestamps, status, and confidence

What EnvPI is designed to avoid by default

• • Full raw secret-value storage as the primary operating model
• • Invisible ingestion of sensitive content
• • Ambiguous boundaries between local analysis and uploaded data
• • Generic “trust us” language without visible handling rules

How .env ingestion should work

When a user imports a .env source, the process should make handling visible. The product should parse the source, identify likely references, show what metadata will be captured, and make redaction obvious before anything is persisted. That gives the user a reviewable boundary instead of a black box.

How repository scanning should work

Repository scanning should focus on evidence building: references, dependency manifests, configuration patterns, likely exposures, and provenance. The goal is not to silently ingest everything possible. The goal is to provide enough structured context to support reliable findings and next-step recommendations.

How local scanning should work

Local analysis should emphasize hygiene and visibility, especially around ignored files, duplicated references, and workspace sprawl. Users should be able to understand what the local scanner examines, what remains local, and what signals become part of the evidence record.

Trust comes from visible boundaries

A product like EnvPI earns trust by making its decisions inspectable. Users should be able to see where a finding came from, what evidence supports it, which source introduced the relevant fact, and what assumptions were made along the way. Provenance is not only useful for debugging the system. It is also part of the trust model.