1. Security principles
Veda applies defense in depth across the stack:
- TLS in transit, encryption at rest, RBAC in application code, and Postgres Row Level Security (RLS) at the database.
- Least privilege: workspace roles and project-level membership.
- Tenant isolation: every customer workspace is a separate tenant; queries are scoped by workspace_id.
- Data minimization: health sync stores numerical metrics and project keys, not Jira issue text or durable project display names.
2. Multi-tenant isolation (RLS)
Data is stored in PostgreSQL (via Supabase) with RLS enabled on tenant-bound tables. Policies tie rows to workspace_id and workspace_members.
API routes require authenticated users and validate workspace membership before returning data. Service-role access is used only on the server for sync jobs—never exposed to the browser.
Users only see workspaces they belong to. Members may be restricted to assigned projects. Cross-company leakage via API or authenticated database keys is blocked by RLS, not merely hidden in the UI.
3. Encryption
All client traffic uses HTTPS (TLS). Database and object storage use provider encryption at rest.
OAuth tokens and secrets are stored with application-level encryption (AES-256-GCM) before being written to the database. Secrets are loaded from environment variables, not source code.
4. Authentication and access control
User authentication via Supabase Auth. Sessions use secure HTTP-only cookies. Workspace RBAC (owner, admin, member) and project_membership control heatmap and integration access. Admin paths require explicit server-side super-admin checks.
Knowing a workspace URL or project UUID does not grant access—every API call is authorized against membership and role.
5. Connected services (Jira / OAuth)
Jira: OAuth 2.0, encrypted tokens per workspace, read-oriented scopes. Live enrichment via GET /api/jira/projects/live is RAM-only on the server with no persistence or logging of project display names. Revoke in Veda or Atlassian.
See also our Privacy Policy section on Atlassian API Data Processing. Privacy
6. NDA-aligned analytics storage
For NDA or outsourcing confidentiality: persisted health data uses project keys plus numerical fields (SPI, CPI, hours, task counts, pillar scores). Issue summaries and comments are excluded from scoring sync. Heatmap APIs expose projectKey and metrics—not projectName from the database. Display names are resolved in the browser with fallback to Project PROJ-123.
7. URL and identifier privacy
Workspace URLs use opaque identifiers (UUID fragments), not company or project titles in paths. Authorization is always enforced server-side. URLs are not a security mechanism.
8. Application security practices
Aligned with OWASP Top 10 priorities:
- Broken access control: workspace guards, RLS, project ownership checks.
- Injection: parameterized queries; schema validation on sensitive APIs.
- Authentication failures: centralized auth; protected admin and integration routes.
- Security headers: CSP on app shell; secrets in env only.
9. Logging and sensitive data
We avoid logging Jira project display names, issue text, OAuth tokens, or raw Atlassian error bodies. We may log HTTP status codes, generic error codes, opaque workspace IDs, and sync outcomes.
10. Infrastructure and subprocessors
Typical subprocessors: Supabase (database, auth), Vercel or equivalent (hosting), Atlassian (customer-controlled Jira APIs), transactional email providers if enabled.
Supabase Security — See Supabase Security documentation for provider controls. Data residency depends on project region configuration.
11. Incident response
We maintain procedures to detect anomalies, contain issues (revoke tokens, disable routes), notify customers when required, and remediate. Report suspected incidents via Support with urgency in the subject line.
12. Customer responsibilities
You are responsible for:
- Managing user access and offboarding in your workspace.
- Choosing which projects to connect and sync.
- Complying with Atlassian and internal IT policies.
- Treating Dashboard metrics as inputs to judgment, not sole grounds for HR or legal action.
13. Questions and assessments
We support reasonable security questionnaires for enterprise deals. Under NDA we can discuss RLS summaries, OAuth scopes, subprocessor lists, and our Privacy Policy Atlassian section. Contact us via the Support form.