Data protection and security
M
Michael (Driverforge)
Driver code often handles credentials, tokens, customer identifiers, or other things that shouldn't end up in centralised logging — and most of the time they don't, until somebody accidentally prints one. Data protection would add a set of safeguards that catch that sort of accident before it becomes a problem, and give teams with stricter compliance requirements the controls they need to use Anvil confidently.
At the centre is auto-redaction: common sensitive patterns (API keys, JWTs, credit card numbers, private keys, passwords in URLs, and more) are detected and masked at ingestion, before the data is stored. Because redaction happens up front, the original value is never persisted and there's no way to recover it — which is the point. Alongside redaction, secrets detection alerts your team when something that looked sensitive was intercepted, so you can fix the code path that sent it rather than relying on the safeguard to keep catching it.
Other controls give you coarser-grained protection. An IP allowlist lets you restrict ingestion to known controller or network ranges so unexpected sources can't send data to your project. An audit log records significant organisation actions — logins, member changes, API key creation, integration connections, security setting changes — so you can answer "who did what, and when" after the fact. Enterprise-tier additions include custom redaction patterns, session management, enforced MFA, data export controls, data residency options, and the GDPR/SOC 2 tooling that larger customers need.
What we're thinking:
- Auto-redaction of common sensitive patterns (API keys, JWTs, credit cards, SSNs, private keys, passwords in URLs) at ingestion
- Secrets detection with alerting when sensitive data is intercepted — via email, Slack, Teams, or an issue tracker
- IP allowlist for project ingestion (individual IPs or CIDR ranges)
- Per-API-key IP allowlist for fleet deployments where each key has a known controller
- Audit log of significant organisation actions with filtering and CSV export
- Custom redaction patterns for organisation-specific identifiers (Enterprise)
- Org-wide API key rotation policy (Enterprise) — enforce a maximum key age across all keys
- Session management, enforced MFA, data export controls (Enterprise)
- Data residency, GDPR tooling, long-term audit retention (Enterprise+)
Help us shape this:
- What kinds of sensitive data are you most worried about accidentally ending up in your logs — API keys, customer identifiers, device credentials, something specific to your domain?
- Would an IP allowlist be useful for your deployments, or do your controllers sit behind dynamic IPs that would make it impractical?
- Which of these protections is table-stakes for you to use Anvil, vs. "nice to have eventually"?