Data Protection
Encryption at rest, tamper detection, tenant isolation, rate limiting, and access scope.
Velnoro protects customer data through encryption, tenant isolation, rate limiting, and strict access controls.
Encryption at Rest
Velnoro uses two layers of encryption at rest:
- Application-layer AES-256-GCM: Customer credentials (secrets, tokens) are encrypted in application code before reaching the database.
- Disk-level AES-256: All data at rest (including template submissions, scan results, and metadata) is protected by Supabase-managed disk encryption.
| What's App-Layer Encrypted | Detail |
|---|---|
| Client ID | Your Entra app registration identifier |
| Client Secret | Your Entra app registration secret |
| Refresh Token | Power Platform delegated auth refresh token |
| Access Tokens | Cached OAuth tokens (per-audience) |
Template submission form data and all other structured data are protected by AES-256 disk encryption and row-level security tenant isolation.
Algorithm: AES-256-GCM with 256-bit key, 12-byte random IV per operation, 16-byte authentication tag for tamper detection. Built on Node.js native crypto module (no third-party encryption libraries).
Key management: The encryption key is stored as an environment variable on the application server. It never appears in source code, database configuration, or logs. Keys are rotated quarterly.
Tamper Detection
GCM authenticated encryption means that if anyone modifies the encrypted data in the database (including through a compromised backup), decryption fails with an authentication error rather than returning corrupted credentials.
Tenant Isolation
Every data table in Velnoro is scoped to a single account through Row-Level Security (RLS) policies in the database. One customer can never see another customer's data, even in error states.
- 17 tables with RLS policies
- All queries filter by
account_idat the database level - No application-level filtering that could be bypassed
What Velnoro Accesses
Tenant scanning collects asset metadata only: names, types, owners, environments, creation dates, and status information. Velnoro never accesses flow definitions, app source code, business data processed by your apps, chat content, connector configurations, Dataverse table contents, or Exchange/Teams/SharePoint/OneDrive data.
Documents stores content that your team enters: governance documents, template submissions (free-text form data), and uploaded files (PDF, DOCX, XLSX, images up to 10 MB). All content is protected by AES-256 disk encryption at rest, RLS tenant isolation, private storage with time-limited signed URLs, and file type/size validation. Do not enter regulated data (health records, payment cards, government IDs) unless you have independently ensured compliance.
Rate Limiting
Velnoro implements rate limiting at two layers to protect against abuse:
- Edge layer: Authentication endpoints (sign-in, sign-up, password reset) are rate-limited at the network edge before reaching the application
- Application layer: Server actions that trigger external API calls (scans, connection tests, bulk operations) have per-user and per-account rate limits using sliding window algorithms
Rate limits protect both Velnoro infrastructure and connected customer tenants from excessive API calls.
Infrastructure
| Component | Provider | Purpose |
|---|---|---|
| Application hosting | Vercel | Next.js app, serverless functions, edge network |
| Database | Supabase (PostgreSQL) | Data storage, authentication, row-level security |
| Background jobs | Inngest | Scan orchestration, scheduled tasks |
| Error monitoring | Sentry | Application error tracking (no customer data in payloads) |
| Payments | Stripe | Payment processing (no card data touches Velnoro servers) |
| Rate limiting | Upstash Redis | API rate limiting for scan triggers and connection tests |
All infrastructure runs in US data centers. No customer data is transmitted to or stored in third-party AI services.