Security & Trust

RuneSignal Architecture Trust Document

Last updated: April 2026 · For use in security questionnaires, vendor assessments, and enterprise due diligence.

This document describes the technical security controls implemented in the RuneSignal platform. It is not a penetration test report. A formal pentest programme is planned for Q3 2026 via a HackerOne managed engagement.

Ed25519

Signing

RLS per tenant

Isolation

MFA AAL2

Auth

AES-256 + TLS

Encryption

Append-only

Ledger

1. Cryptographic Signing — Ed25519

Every event written to the RuneSignal audit ledger is signed with an Ed25519 private key before persistence. Ed25519 (RFC 8032) provides 128-bit security with deterministic signatures — suitable for court-admissible audit trails and regulator-presentable evidence packages.

Signing keyEd25519 keypair, generated at tenant provisioning time. Private key stored as an environment secret, never persisted to the database.

Signed payloadSHA-256 hash of tenant_id + agent_id + event_type + timestamp + data_hash — the concatenated canonical string is signed before insert.

VerificationPublic key exposed via GET /api/v1/verify/pubkey. Any party can independently verify a signature without contacting RuneSignal.

ImmutabilityAudit events are insert-only at the database layer. No UPDATE or DELETE is permitted on the audit_events table. The RLS policy enforces this at the Postgres level regardless of application code.

Post-quantum readinessA stub ML-DSA-65 (NIST FIPS 204) dual-signing path exists behind the ENABLE_PQC feature flag. Not marketed until fully implemented and independently audited.

2. Tenant Data Isolation — Row-Level Security

RuneSignal is a multi-tenant SaaS. Every database table that stores customer data includes a tenant_id foreign key referencing the tenants table. Isolation is enforced at the Postgres RLS layer — not only in application code.

Enforcement pointSupabase PostgreSQL Row-Level Security policies on every tenant-scoped table. Even if application code contains a bug, a query from Tenant A cannot return rows belonging to Tenant B.

Policy patternCREATE POLICY tenant_isolation ON [table] FOR ALL USING (tenant_id = (SELECT tenant_id FROM tenant_members WHERE user_id = auth.uid()));

Admin operationsBackend service operations (audit writes, webhook delivery, NHI rotation) use a Supabase service-role client that bypasses RLS. This client is never exposed to the browser or API consumers.

API key isolationAPI keys are stored as SHA-256 hashes. Middleware resolves a key to its tenant_id at the edge and injects it as an X-Tenant-Id header. All downstream queries are scoped to that tenant ID.

VerificationCustomers can verify tenant isolation by inspecting the migration files at supabase/migrations/ in the public GitHub repository.

3. Authentication — MFA AAL2 Enforcement

All RuneSignal dashboard access requires a valid Supabase session. If a user has enrolled a TOTP factor, the platform enforces Authenticator Assurance Level 2 (AAL2) before any dashboard route is accessible.

MFA methodTOTP (RFC 6238) via Supabase Auth. Compatible with Google Authenticator, Authy, 1Password, and any RFC 6238-compliant app.

AAL2 enforcementMiddleware calls supabase.auth.mfa.getAuthenticatorAssuranceLevel() on every request. If nextLevel === 'aal2' and currentLevel !== 'aal2', the user is redirected to the MFA challenge page — regardless of session validity.

API key authMachine-to-machine access uses scoped API keys (tl_* prefix). Keys are stored as SHA-256 hashes. The plaintext key is shown exactly once at generation time.

Session handlingSessions managed by Supabase Auth (JWT, httpOnly cookies). Token refresh handled server-side via @supabase/ssr. No tokens stored in localStorage.

Brute force protectionSupabase Auth enforces rate limits on authentication attempts at the infrastructure level. Application-level rate limiting via Upstash Redis (100 req/min per tenant) provides additional protection.

4. Encryption — At Rest and In Transit

All customer data is encrypted both at rest and in transit. RuneSignal does not operate its own database infrastructure — storage is delegated to Supabase (Postgres on AWS), which provides managed encryption.

Encryption at restAES-256 via Supabase PostgreSQL on AWS RDS. Managed key rotation handled by AWS KMS. No plaintext data written to disk.

Encryption in transitTLS 1.2 minimum enforced on all endpoints. TLS 1.3 supported and preferred. Vercel enforces HTTPS for all deployments; HTTP requests are automatically redirected.

Secret managementApplication secrets (service role key, Ed25519 private key, Stripe key, CRON secret) stored as environment variables in Vercel. Never committed to source control. .env* files are in .gitignore.

API key storageAPI keys hashed with SHA-256 before database insert. The hash is used for verification; the plaintext key is never stored.

5. Rate Limiting and API Abuse Prevention

RuneSignal applies rate limiting at the edge (middleware layer) before any request reaches application code or the database.

Per-tenant rate limit100 requests per minute per tenant, enforced via Upstash Redis sliding window algorithm at the Next.js middleware layer.

Plan-based limitsAPI usage is metered per tenant per month. Tenants exceeding their plan limit receive HTTP 429 with an upgrade URL. Prevents runaway agent loops from consuming unbounded resources.

CRON endpoint securityAll scheduled job endpoints (/api/cron/*) require a Bearer token matching the CRON_SECRET environment variable. Unauthenticated requests return HTTP 401.

Response headersEvery response includes X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers for client-side backoff implementation.

6. Vulnerability Management

RuneSignal follows a structured approach to identifying and remediating security vulnerabilities.

Dependency scanningGitHub Dependabot enabled on the repository. Automated PRs raised for known CVEs in npm dependencies. Critical and high severity issues targeted for resolution within 7 days.

OWASP ZAPAutomated OWASP ZAP baseline scan runs weekly via GitHub Actions against the production deployment. Scan reports are retained as artefacts for 90 days. Results reviewed on each run.

Bug bountyA HackerOne-managed bug bounty programme is planned for Q2 2026. Scope: all /api/v1/* endpoints and the dashboard application.

Penetration testA formal penetration test via Cobalt.io or equivalent is planned for Q3 2026, required before any enterprise deal with a regulated buyer.

Incident responseP1 security incidents are acknowledged within 15 minutes (see SLA). The Customer is notified of any Personal Data breach within 72 hours per GDPR Article 33.

7. Infrastructure and Supply Chain

RuneSignal is built on a minimal, auditable supply chain of established cloud infrastructure providers.

HostingVercel (application layer). Vercel is SOC 2 Type II certified and ISO 27001 compliant.

DatabaseSupabase (PostgreSQL). Supabase is SOC 2 Type II certified. Data hosted on AWS.

Edge rate limitingUpstash Redis. Upstash is SOC 2 Type II certified.

PaymentsStripe (billing only). Stripe is PCI DSS Level 1 certified. No payment card data passes through RuneSignal infrastructure.

Source codeHosted on GitHub. Branch protection rules enforced on main and dev. All changes require pull request review.

8. Regulatory Compliance Posture

Framework	Status	Notes
GDPR	Implemented	DPA available. RLS, encryption, deletion rights, breach notification in place.
EU AI Act (Articles 13, 14, 17, 26)	Core capability	Evidence export endpoint generates article-mapped compliance packages.
ISO 42001	Partial	Clause 9 evidence mapping in progress. Full certification not yet pursued.
SOC 2 Type I	Planned Q3 2026	Observation period begins Q2 2026. Required for US enterprise buyers.
SOC 2 Type II	Roadmap	12-month observation required after Type I.
ISO 27001	Roadmap	Post Series A priority.
HIPAA	Roadmap	Available on Enterprise tier with BAA. Timeline subject to customer demand.

Security enquiries: security@runesignal.ai · Data Processing Agreement · Service Level Agreement

RuneSignal Architecture Trust Document · April 2026 · This document is provided for informational purposes only and does not constitute a warranty or guarantee of security. Controls are subject to change with notice.