Last Updated: 2026-03-21
Security Practices
Hone Studio was built for organizations that handle sensitive institutional data. Security is enforced in code, at every layer, from the database to the browser.
What We Eliminated
Some of the most important security decisions are about what we chose not to build.
Passwords
No password database exists. Nothing to steal.
Session Cookies
JWT-only authentication. No persistent cookies to hijack.
Shared Infrastructure
No shared database, server, or deployment between clients.
Stored API Keys
Keys are bcrypt-hashed. We never store the plaintext.
Cross-Client Access
Architecturally impossible. Seven isolation layers enforce it.
Encryption
| Layer | Standard | Implementation |
|---|---|---|
| Data at rest | AES-256 | AWS KMS managed keys via Supabase. All client data, embeddings, uploaded files, and backups encrypted |
| Data in transit | TLS 1.2+ | All connections — browser to frontend, frontend to backend, backend to database, backend to AI providers |
| HSTS | Strict Transport Security | Enforced on all domains. Browsers forced to HTTPS |
| API keys | bcrypt | API key hashes use bcrypt with per-key salts. No passwords exist in the system |
| Backups | AES-256 | Database backups encrypted by Supabase/AWS at the storage layer |
Layer
Data at rest
Standard
AES-256
Implementation
AWS KMS managed keys via Supabase. All client data, embeddings, uploaded files, and backups encrypted
Layer
Data in transit
Standard
TLS 1.2+
Implementation
All connections — browser to frontend, frontend to backend, backend to database, backend to AI providers
Layer
HSTS
Standard
Strict Transport Security
Implementation
Enforced on all domains. Browsers forced to HTTPS
Layer
API keys
Standard
bcrypt
Implementation
API key hashes use bcrypt with per-key salts. No passwords exist in the system
Layer
Backups
Standard
AES-256
Implementation
Database backups encrypted by Supabase/AWS at the storage layer
Authentication
Hone Studio is passwordless by design. There are no passwords in the system — nothing to steal, nothing to reuse, nothing to reset.
| Method | Use Case | Details |
|---|---|---|
| Magic link (email OTP) | Primary login for web users | Passwordless — no credentials to steal or reuse |
| Google OAuth (SSO) | Alternative login for web users | Standard OAuth 2.0 flow. Only pre-approved accounts |
| API keys | External integrations | Bcrypt-hashed storage, timing-attack-mitigated verification |
Method
Magic link (email OTP)
Use Case
Primary login for web users
Details
Passwordless — no credentials to steal or reuse
Method
Google OAuth (SSO)
Use Case
Alternative login for web users
Details
Standard OAuth 2.0 flow. Only pre-approved accounts
Method
API keys
Use Case
External integrations
Details
Bcrypt-hashed storage, timing-attack-mitigated verification
Authentication Methods
JWT Security
| Control | Implementation |
|---|---|
| Algorithm validation | Only HS256 and ES256 accepted. Other algorithms rejected immediately |
| JWKS rotation | ES256 keys verified via JWKS endpoint with automatic rotation |
| Token expiry | Short-lived tokens with minimal clock skew tolerance |
| Audience validation | Tokens must carry authenticated audience claim |
Control
Algorithm validation
Implementation
Only HS256 and ES256 accepted. Other algorithms rejected immediately
Control
JWKS rotation
Implementation
ES256 keys verified via JWKS endpoint with automatic rotation
Control
Token expiry
Implementation
Short-lived tokens with minimal clock skew tolerance
Control
Audience validation
Implementation
Tokens must carry authenticated audience claim
Access is restricted to an explicit allowlist. Only pre-approved email addresses or domains can authenticate. Unauthorized accounts are rejected at the identity layer before reaching any application code.
Authorization & Multi-Tenant Isolation
Every client operates on fully isolated infrastructure. There is no shared data layer between clients.
Infrastructure Isolation
| Layer | Approach | Details |
|---|---|---|
| Database | Separate Supabase project per client | Independent PostgreSQL instance, Auth service, and storage buckets |
| Backend API | Separate Railway service per client | Independent API deployment with its own environment variables |
| Frontend | Separate Vercel deployment per client | Dedicated domain per client |
Layer
Database
Approach
Separate Supabase project per client
Details
Independent PostgreSQL instance, Auth service, and storage buckets
Layer
Backend API
Approach
Separate Railway service per client
Details
Independent API deployment with its own environment variables
Layer
Frontend
Approach
Separate Vercel deployment per client
Details
Dedicated domain per client
Within each client environment, defense-in-depth prevents any lateral access between users and workspaces.
Application-Level Isolation
| Mechanism | Implementation | Prevents |
|---|---|---|
| Row-Level Security | PostgreSQL RLS policies filter every query | Cross-tenant data access at the SQL level |
| Table prefixing | Client-prefixed database tables | Accidental data mixing |
| Storage buckets | Client-specific Supabase Storage buckets | Cross-tenant file access |
| Configuration isolation | Separate configuration directories per client | Configuration bleed between clients |
| Workspace scoping | All operations scoped to user's workspace | Cross-workspace access within a client |
Mechanism
Row-Level Security
Implementation
PostgreSQL RLS policies filter every query
Prevents
Cross-tenant data access at the SQL level
Mechanism
Table prefixing
Implementation
Client-prefixed database tables
Prevents
Accidental data mixing
Mechanism
Storage buckets
Implementation
Client-specific Supabase Storage buckets
Prevents
Cross-tenant file access
Mechanism
Configuration isolation
Implementation
Separate configuration directories per client
Prevents
Configuration bleed between clients
Mechanism
Workspace scoping
Implementation
All operations scoped to user's workspace
Prevents
Cross-workspace access within a client
1Infrastructure Separation
Separate Supabase, Railway, and Vercel deployment per client2Database Isolation
Independent PostgreSQL database per client3Table Prefixing
Client-prefixed table names prevent cross-query4Row-Level Security
Database-enforced policies on every query5Storage Buckets
Client-specific file storage with access policies6API Key Scoping
Keys bound to a single client, bcrypt-hashed7Workspace Scoping
Application-level access control within each deployment7 independent mechanisms — any single layer prevents cross-client access
In total, seven independent mechanisms must all fail simultaneously before any cross-tenant data exposure could occur.
Input Validation & Injection Prevention
| Attack Vector | Mitigation |
|---|---|
| SQL injection | All queries use parameterized queries. Pattern-matching input escaped |
| XSS | Framework-default output escaping, Content-Security-Policy header |
| SSRF | External URL fetches validated — private/internal IP ranges blocked |
| CSRF | SameSite cookie attribute, Bearer token authentication |
| Prompt injection | System prompts set server-side. Tool outputs sanitized. Parameter allowlist |
| Request validation | All API inputs validated by typed schema models |
Attack Vector
SQL injection
Mitigation
All queries use parameterized queries. Pattern-matching input escaped
Attack Vector
XSS
Mitigation
Framework-default output escaping, Content-Security-Policy header
Attack Vector
SSRF
Mitigation
External URL fetches validated — private/internal IP ranges blocked
Attack Vector
CSRF
Mitigation
SameSite cookie attribute, Bearer token authentication
Attack Vector
Prompt injection
Mitigation
System prompts set server-side. Tool outputs sanitized. Parameter allowlist
Attack Vector
Request validation
Mitigation
All API inputs validated by typed schema models
Rate Limiting
All API endpoints are protected by Redis-backed token bucket rate limiting with tiered limits based on operation type and authentication status.
| Scope | Limit | Purpose |
|---|---|---|
| Authenticated requests | Tiered limits | General abuse prevention |
| Anonymous requests | Restricted | Unauthenticated endpoint protection |
| LLM operations | Tiered limits | AI provider cost control |
| Upload operations | Restricted | Storage abuse prevention |
| Auth attempts | Restricted | Brute-force protection |
| API key requests | Per-key configurable | Integration-specific limits |
Scope
Authenticated requests
Limit
Tiered limits
Purpose
General abuse prevention
Scope
Anonymous requests
Limit
Restricted
Purpose
Unauthenticated endpoint protection
Scope
LLM operations
Limit
Tiered limits
Purpose
AI provider cost control
Scope
Upload operations
Limit
Restricted
Purpose
Storage abuse prevention
Scope
Auth attempts
Limit
Restricted
Purpose
Brute-force protection
Scope
API key requests
Limit
Per-key configurable
Purpose
Integration-specific limits
Security over availability:
When rate limits are exceeded, requests are rejected immediately. We do not queue, retry, or degrade — the request fails cleanly with a clear error. This is a deliberate trade-off: we prefer temporary service interruption over allowing potential abuse to continue.
Security Headers
| Header | Value | Purpose |
|---|---|---|
| Strict-Transport-Security | max-age=63072000; includeSubDomains | Force HTTPS for 2 years |
| X-Frame-Options | DENY | Prevent clickjacking |
| X-Content-Type-Options | nosniff | Prevent MIME type sniffing |
| Content-Security-Policy | Restrictive policy | Control resource loading origins |
| Referrer-Policy | strict-origin-when-cross-origin | Limit referrer leakage |
| Permissions-Policy | Restrictive | Disable unnecessary browser APIs |
| X-DNS-Prefetch-Control | off | Prevent DNS prefetch leakage |
Header
Strict-Transport-Security
Value
max-age=63072000; includeSubDomains
Purpose
Force HTTPS for 2 years
Header
X-Frame-Options
Value
DENY
Purpose
Prevent clickjacking
Header
X-Content-Type-Options
Value
nosniff
Purpose
Prevent MIME type sniffing
Header
Content-Security-Policy
Value
Restrictive policy
Purpose
Control resource loading origins
Header
Referrer-Policy
Value
strict-origin-when-cross-origin
Purpose
Limit referrer leakage
Header
Permissions-Policy
Value
Restrictive
Purpose
Disable unnecessary browser APIs
Header
X-DNS-Prefetch-Control
Value
off
Purpose
Prevent DNS prefetch leakage
CI/CD & Change Management
| Check | Tool | Frequency |
|---|---|---|
| JavaScript/TypeScript linting | ESLint | Every push and PR |
| Python linting | ruff | Every push and PR |
| Type checking | TypeScript compiler | Every push and PR |
| Frontend unit tests | Vitest | Every push and PR |
| Backend unit tests | pytest | Every push and PR |
| E2E tests | Playwright (400+ tests) | Every push and PR |
| Static security analysis | CodeQL | Every push/PR + weekly deep scan |
| Dependency vulnerability scanning | Dependabot | Weekly (npm, pip, GitHub Actions) |
| Secret scanning | GitHub Secret Scanning | Push protection + AI detection on every commit |
| Container & filesystem scanning | Trivy | Every push/PR + weekly scheduled rescan |
| Format checking | Prettier / ruff | Every push and PR |
Check
JavaScript/TypeScript linting
Tool
ESLint
Frequency
Every push and PR
Check
Python linting
Tool
ruff
Frequency
Every push and PR
Check
Type checking
Tool
TypeScript compiler
Frequency
Every push and PR
Check
Frontend unit tests
Tool
Vitest
Frequency
Every push and PR
Check
Backend unit tests
Tool
pytest
Frequency
Every push and PR
Check
E2E tests
Tool
Playwright (400+ tests)
Frequency
Every push and PR
Check
Static security analysis
Tool
CodeQL
Frequency
Every push/PR + weekly deep scan
Check
Dependency vulnerability scanning
Tool
Dependabot
Frequency
Weekly (npm, pip, GitHub Actions)
Check
Secret scanning
Tool
GitHub Secret Scanning
Frequency
Push protection + AI detection on every commit
Check
Container & filesystem scanning
Tool
Trivy
Frequency
Every push/PR + weekly scheduled rescan
Check
Format checking
Tool
Prettier / ruff
Frequency
Every push and PR
All checks must pass before code can be merged. There are no override mechanisms — CI failures block deployment.
We run our own code first. New releases deploy to our internal environment (Hone Labs) before reaching any client. This canary deployment model means we catch regressions on ourselves before they affect the institutions we serve.
Monitoring & Error Handling
| Capability | Details |
|---|---|
| Error monitoring | Real-time tracking configured to scrub known PII patterns |
| Performance monitoring | Performance traces on critical paths |
| Structured logging | Every request carries a unique correlation ID through the entire chain |
| Health checks | Endpoint monitors database, cache, and service status |
| Self-healing operations | Background job monitor detects stuck operations and auto-recovers |
| Circuit breakers | All external API calls protected — graceful degradation when providers are down |
| Error handling | Typed error hierarchy — no raw exception details exposed to clients |
Capability
Error monitoring
Details
Real-time tracking configured to scrub known PII patterns
Capability
Performance monitoring
Details
Performance traces on critical paths
Capability
Structured logging
Details
Every request carries a unique correlation ID through the entire chain
Capability
Health checks
Details
Endpoint monitors database, cache, and service status
Capability
Self-healing operations
Details
Background job monitor detects stuck operations and auto-recovers
Capability
Circuit breakers
Details
All external API calls protected — graceful degradation when providers are down
Capability
Error handling
Details
Typed error hierarchy — no raw exception details exposed to clients
AI-Specific Security
| Control | Details |
|---|---|
| Data retention | Zero-retention confirmed with Google and Perplexity. Zero-retention agreements requested from Anthropic and Cohere (pending confirmation) |
| No model training | Your data is never used to train or improve AI models |
| Data minimization | Only minimum necessary data included in prompts |
| Parameter whitelisting | Strict allowlist restricts parameters flowing to LLM API |
| Token budgets | Configurable hourly and daily limits prevent runaway operations |
| Kill switches | Feature toggles allow immediate disabling of AI capabilities |
| Usage tracking | Every AI call logged with user, model, tokens, cost, and latency |
Control
Data retention
Details
Zero-retention confirmed with Google and Perplexity. Zero-retention agreements requested from Anthropic and Cohere (pending confirmation)
Control
No model training
Details
Your data is never used to train or improve AI models
Control
Data minimization
Details
Only minimum necessary data included in prompts
Control
Parameter whitelisting
Details
Strict allowlist restricts parameters flowing to LLM API
Control
Token budgets
Details
Configurable hourly and daily limits prevent runaway operations
Control
Kill switches
Details
Feature toggles allow immediate disabling of AI capabilities
Control
Usage tracking
Details
Every AI call logged with user, model, tokens, cost, and latency
For a complete description of how AI is governed in the platform, see our AI Governance page.
Backup & Recovery
| Asset | Method | Frequency | RTO |
|---|---|---|---|
| Database | Supabase automated + WAL streaming | Daily + continuous WAL | < 4 hours |
| File storage | With database backup | Daily | < 4 hours |
| Application code | Git (GitHub) | Every commit | < 15 minutes |
| Frontend | Vercel deployment history | Every deployment | < 1 minute |
| Backend | Railway deployment history | Every deployment | < 15 minutes |
Asset
Database
Method
Supabase automated + WAL streaming
Frequency
Daily + continuous WAL
RTO
< 4 hours
Asset
File storage
Method
With database backup
Frequency
Daily
RTO
< 4 hours
Asset
Application code
Method
Git (GitHub)
Frequency
Every commit
RTO
< 15 minutes
Asset
Frontend
Method
Vercel deployment history
Frequency
Every deployment
RTO
< 1 minute
Asset
Backend
Method
Railway deployment history
Frequency
Every deployment
RTO
< 15 minutes
Backup restoration testing is scheduled per the plan. Recovery procedures are documented and version-controlled alongside application code.
Compliance
| Framework | Status |
|---|---|
| FERPA | Designed to meet FERPA requirements — school official safeguards, zero AI data retention (confirmed or requested), 24-hour breach notification |
| HECVAT 4 | Completed — 351 claims verified, 14/16 domains HIGH. Available on request |
| SOC 2 Type II | Not yet certified. Third-party assessment planned Q3 2026, Type I targeted Q1–Q2 2027 |
| VPAT / ACR (Section 508) | Completed — March 2026 (46/50 WCAG 2.1 AA criteria fully supported) |
| NY Education Law 2-d | Designed to meet 2-d requirements — no commercial use of student data |
| California SOPIPA | Designed to meet SOPIPA requirements — no student profiling or advertising |
| Security assessment | Self-administered first-party assessment completed March 2026 (OWASP WSTG v4.2). Independent third-party assessment planned Q3 2026 |
| Cyber liability insurance | Active — Hiscox Professional Liability, Cyber Liability, and General Liability ($1M per occurrence). Certificate available on request |
Framework
FERPA
Status
Designed to meet FERPA requirements — school official safeguards, zero AI data retention (confirmed or requested), 24-hour breach notification
Framework
HECVAT 4
Status
Completed — 351 claims verified, 14/16 domains HIGH. Available on request
Framework
SOC 2 Type II
Status
Not yet certified. Third-party assessment planned Q3 2026, Type I targeted Q1–Q2 2027
Framework
VPAT / ACR (Section 508)
Status
Completed — March 2026 (46/50 WCAG 2.1 AA criteria fully supported)
Framework
NY Education Law 2-d
Status
Designed to meet 2-d requirements — no commercial use of student data
Framework
California SOPIPA
Status
Designed to meet SOPIPA requirements — no student profiling or advertising
Framework
Security assessment
Status
Self-administered first-party assessment completed March 2026 (OWASP WSTG v4.2). Independent third-party assessment planned Q3 2026
Framework
Cyber liability insurance
Status
Active — Hiscox Professional Liability, Cyber Liability, and General Liability ($1M per occurrence). Certificate available on request
Vulnerability Management
- •Dependencies are monitored continuously via GitHub Dependabot (weekly scans for npm, pip, and GitHub Actions). CodeQL static security analysis runs on every push/PR plus weekly deep scans covering JavaScript/TypeScript and Python. GitHub Secret Scanning with push protection blocks commits containing secrets
- •Critical vulnerabilities are patched within 24 hours of disclosure
- •Security issues can be reported through our responsible disclosure program
See our Responsible Disclosure page for reporting guidelines and safe harbor terms.
Request Detailed Documentation
- •HECVAT 4 workbook — completed (higher education)
- •SOC 2 readiness assessment
- •VPAT / Accessibility Conformance Report — completed
- •Data Processing Agreement (DPA)
- •Network architecture diagram
- •Incident response plan
- •Business continuity plan
- •Vendor risk assessment
- •Security assessment results (first-party report available)
- •Custom security questionnaire completion
Contact security@honelabs.dev to request any of the above or to schedule a security review call.