Security Whitepaper

Version 1.0 · Last updated March 10, 2026

Executive Summary

Velnoro is a capability intelligence platform for citizen development. Organizations connect their Microsoft Power Platform tenant so Velnoro can discover, inventory, and govern their low-code assets (apps, flows, agents, and environments).

Velnoro's security model is built on three principles:

• Read-only access. Velnoro never writes to, modifies, or deletes anything in a customer's Microsoft tenant.
• Metadata only (tenant scanning). Velnoro collects asset metadata (names, types, owners, environments, dates). It never accesses flow definitions, app source code, business data, or chat content. The Program Resources feature additionally stores customer-entered governance documents and uploaded files.
• Customer-controlled. Customers connect using their own Azure Entra ID app registration, which they can revoke at any time.

This document describes Velnoro's security architecture for organizations evaluating the platform as part of their procurement, compliance, or security review process.

Platform Overview

Velnoro is a cloud-hosted web application. Customers sign in, connect their Microsoft tenant, and run scans that query Microsoft APIs for asset metadata. The results power governance dashboards, health scoring, and program management tools.

Data flow:

1. Customer creates an Entra ID app registration in their own Azure tenant and grants it read-only permissions
2. Customer enters credentials in Velnoro and authorizes Power Platform access via a one-time admin consent flow
3. Velnoro queries Microsoft Graph and Power Platform Inventory APIs using the customer's app registration
4. Metadata responses are normalized, encrypted where appropriate, and stored in Velnoro's database
5. Customers view results through dashboards, reports, and governance tools

Velnoro's application runs on managed cloud infrastructure. The database, application hosting, and background job processing are provided by established cloud platforms (see Infrastructure section). All components run in US data centers.

Authentication and Authorization

User Authentication

Velnoro supports three sign-in methods:

Multi-factor authentication (MFA) is supported. Identity linking allows users who signed up with one method to later connect additional sign-in providers without creating duplicate accounts.

Session tokens are managed via httpOnly cookies. All sensitive operations (credential handling, API calls, database writes) run exclusively on the server. The client-side application never handles credentials or encryption keys.

Customer Tenant Authentication

Velnoro uses a “bring your own app registration” model. The customer creates an Entra ID app registration in their own Azure tenant and grants it specific, minimal permissions. Velnoro never operates a shared multi-tenant application.

Why this matters for security teams:

• Customer controls access. The app registration lives in your tenant. Delete it or revoke its secret at any time to immediately cut off Velnoro's access.
• No multi-tenant app consent. Your security team reviews only your own app registration, not a third-party shared app.
• Full audit trail. All API calls appear in your Entra ID sign-in logs under your app registration's service principal.
• Principle of least privilege. You grant exactly two read-only permissions (see Data Handling section).

Shared Responsibility Model

OAuth Flow Security

The authorization flow for Power Platform access includes:

• CSRF protection via cryptographically signed state parameters (HMAC-SHA256) that prevent forged callback attacks
• PKCE (Proof Key for Code Exchange, RFC 7636) that prevents authorization code interception, even for confidential clients
• Constant-time signature verification to prevent timing attacks

Encryption

At Rest

All customer credentials are encrypted at the application layer before reaching the database. All other data at rest is protected by Supabase-managed AES-256 disk encryption.

What is app-layer encrypted: Client IDs, client secrets, refresh tokens, and cached access tokens. Every credential field is encrypted individually with a unique initialization vector. Template submission form data and other structured content are protected by AES-256 disk encryption and row-level security.

What is not encrypted (not sensitive): Tenant IDs (public directory identifiers), platform type, connection type, and operational status fields.

Tamper Detection

GCM's authentication tag ensures that if encrypted data is modified in the database (including through a compromised backup), decryption fails with an authentication error rather than returning corrupted credentials. This provides integrity verification in addition to confidentiality.

Key Management

The encryption key is stored as an environment variable on the application server. It never appears in source code, database configuration, or application logs. Keys are rotated quarterly using a dedicated rotation utility that re-encrypts all credential fields. The rotation process supports dry-run mode and per-row error isolation to prevent partial corruption.

In Transit

All communications between Velnoro and external services (Microsoft APIs, database, client browsers) are encrypted via TLS.

Tenant Isolation

Customer data isolation is enforced at the database level through Row-Level Security (RLS) policies. This is not application-level filtering that could be bypassed by a code bug; it is enforced by the database engine itself.

Key properties:

• Every customer data table has RLS policies that scope queries to the requesting account
• All queries filter by account_id at the database level
• One customer can never see another customer's data, even in error states
• A formal RLS audit confirmed 100% coverage across all customer data tables, with no critical gaps

Admin client usage: A privileged database client that bypasses RLS exists for system operations only (automated data retention cleanup, OAuth callback processing). All admin client usage includes explicit authorization checks.

Data Handling

Read-Only Guarantee

Velnoro never writes to, modifies, creates, or deletes anything in a customer's Microsoft tenant. All API calls are read-only queries. The permissions Velnoro requests do not grant write access to any Microsoft API surface.

Metadata Only

Velnoro collects asset metadata: names, types, owners, environments, creation dates, and status information.

Velnoro does NOT access:

• Flow definitions or automation logic
• App source code or formulas
• Business data processed by flows or apps
• Chat or conversation content
• Connector configurations or credentials used by customer flows
• Dataverse table contents
• Exchange, Teams, SharePoint, or OneDrive data

Customer-Entered Content

In addition to read-only tenant scanning, Velnoro's Program Resources feature allows customers to create governance documents, fill out templates, and upload files (PDF, DOCX, XLSX, images up to 10 MB). This content is stored in Velnoro's systems and protected by the same controls as all other customer data:

• RLS tenant isolation on all tables and storage buckets
• Private storage bucket with signed URLs (5-minute expiry) for downloads
• File type validation (whitelist of allowed MIME types) and 10 MB size limit
• Path traversal prevention via UUID-based storage paths scoped to the customer's account
• Cascade deletion when an account is deleted

Important: Velnoro is not designed to store regulated data (health records, payment card numbers, government IDs). Customers are responsible for ensuring the content they enter or upload complies with applicable laws. Velnoro does not guarantee the safety, security, or compliance outcomes of customer's citizen development programs. Velnoro is an intelligence and visibility tool; governance decisions and enforcement remain the customer's responsibility.

API Permissions

Velnoro requires exactly two API permissions, both read-only:

A formal permission minimization audit confirmed zero unused permissions and zero overreach. Every requested permission maps to an active feature. No write, create, or delete permissions are requested for any Microsoft API surface.

Error Handling

API error responses from Microsoft may contain tenant-specific details. All errors are sanitized before storage or display. Only status codes, error codes, and safe descriptions are retained. Raw response bodies and internal correlation IDs are not exposed in the user interface.

Data Retention and Deletion

Retention Policy

Retention is enforced automatically by a daily background job that removes expired scan data. Credential data (encrypted client secrets, refresh tokens) is retained as long as the connection exists, regardless of tier.

Account Deletion

When a customer deletes their account, all associated data is permanently removed:

• All platform connections and encrypted credentials are deleted
• All scan records, asset metadata, and environment data cascade-delete
• Stripe subscriptions are cancelled
• No orphaned data remains

Encrypted credential fields are securely zeroed before deletion.

No Data Sharing

Customer data is never sold, shared with, or transmitted to third parties for marketing, analytics, or any other purpose. No customer data is sent to AI services.

Infrastructure

Velnoro runs on managed cloud infrastructure provided by established vendors. All components are hosted in US data centers.

Subprocessors

Rate Limiting

Velnoro implements rate limiting at two layers to protect against brute-force attacks and API abuse:

• Edge layer: Authentication endpoints 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

Server-Side Security

All sensitive operations run on the server:

• Credential encryption and decryption
• Token acquisition and refresh
• Microsoft API calls
• Database writes
• Scan pipeline execution

The client-side application never handles credentials, tokens, or encryption keys. No API keys or server secrets are exposed to the browser.

Incident Response

Error Monitoring

Velnoro uses application error monitoring with PII scrubbing enabled. Customer credentials, tenant identifiers, and raw API responses are excluded from error reports. Error payloads contain only the information needed to diagnose and fix application issues.

Breach Impact Limitation

In the event of a database breach, customer credentials are protected by AES-256-GCM application-layer encryption. An attacker with database access cannot read credential fields without the encryption key, which is stored separately in the application environment. All other data (including template submissions and uploaded documents) is protected by AES-256 disk encryption at the infrastructure level. Additionally, because Velnoro's access to customer tenants is read-only, a breach cannot result in modifications to customer platform resources.

Notification

In the event of a security incident affecting customer data, Velnoro will notify affected customers promptly via their registered email addresses with details of the incident, its scope, and remediation steps.

Contact

• Email: support@velnoro.com
• Trust Center: app.velnoro.com/trust

Compliance Roadmap

Request Detailed Documentation

This whitepaper covers Velnoro's public security posture. Additional documentation is available upon request for organizations conducting in-depth security evaluations:

• Detailed security questionnaire responses
• Penetration test summaries
• Detailed infrastructure documentation
• Security policy documents
• Signed security addendum

About Velnoro

Velnoro is built by Velnoro LLC, based in Raleigh, NC. Velnoro helps organizations discover, govern, and enable their citizen development programs on Microsoft Power Platform.

• Website: velnoro.com
• Trust Center: app.velnoro.com/trust
• Security Contact: support@velnoro.com