Security

1. Summary

• HTTPS-everywhere with TLS 1.3.
• AES-256-GCM envelope encryption for customer-controlled secrets (BYOK keys, OAuth tokens).
• Relationship-based access control (ReBAC) for every cross-tenant action.
• Append-only audit log on every authenticated mutation, with dual-actor records when staff acts on behalf of a customer.
• Production secrets protected by encrypted-at-rest vaulting with offline key distribution.
• Public vulnerability disclosure policy with a 90-day disclosure window.

2. Infrastructure

Steward runs on managed cloud infrastructure with the following security posture:

• Process isolation — web, worker, and authorization processes run as separate workloads with no shared filesystem or local network surface.
• Edge protection — frontend traffic is served from a CDN with DDoS mitigation and a managed WAF in front of every request.
• Encrypted databases — managed PostgreSQL with TLS-enforced connections and at-rest encryption at the storage layer.
• Separated authorization plane — the authorization service runs on its own workload with its own database, independent of the application database lifecycle.
• Centralised observability — logs and metrics ship over authenticated TLS to a managed observability stack; no log volumes are mounted to compute hosts.

The specific vendors we rely on are subject to change without notice as we evolve the platform. If your procurement process requires a current subprocessor list, contact security@trendvidia.com.

3. Encryption

In transit: TLS 1.3 for every external connection. HSTS preload on the steward-dev.ai apex. Internal traffic between our workloads runs over a private network and is additionally TLS-terminated at the service boundary where applicable.

At rest:

• Production databases are encrypted at rest by the managed-database provider at the storage layer.
• Application-level envelope encryption (AES-256-GCM) protects customer-controlled secrets — BYOK API keys, captured OAuth tokens. Additional authenticated data (AAD) bindings make a row's ciphertext non-portable to a different row.
• Long-lived session tokens are stored as SHA-256 hashes; the cleartext only exists in the user's cookie.
• API tokens are stored as SHA-256 hashes; the plaintext is shown once at mint time and never again.

4. Authentication & authorization

Authentication uses GitHub OAuth for the standard customer path and OpenID Connect (OIDC) for enterprise SSO. Sessions are HttpOnly + Secure + SameSite=Lax with a 30-day sliding window.

Authorization is centralised in a relationship-based access-control plane. Every cross-tenant read or write resolves a permission check before the action proceeds. Roles cover owner, sponsor, project manager, maintainer, auditor, billing admin, and member-manager personas. Staff capabilities are tiered across super-staff, read-only-staff, impersonator-only, billing-exempt-only, and sales-admin levels.

Staff impersonation requires an explicit permission and records a dual-actor row in the audit log: the impersonated user as actor, the staff member as impersonator. The audit chain of custody is preserved across the impersonation session.

5. Secrets management

Operator secrets (database credentials, signing keys, third-party API credentials) are vaulted in encrypted-at-rest form. Decryption requires an environment-specific private key distributed via offline channels; no single operator's workstation holds keys to more than one environment. Production workloads receive resolved secrets at deploy time via the platform's secret-injection mechanism — secrets never land on disk in cleartext on the running host.

Key rotation is supported for every operator credential. Rotating an environment's encryption key re-seals that environment's secret material.

6. Audit & monitoring

Every authenticated mutation is recorded in an append-only audit log with the actor, IP, User-Agent, target resource, and a structured metadata payload. Staff actions performed under impersonation carry both the impersonated user and the staff actor on the same record. The audit log is append-only at the application layer.

Application logs ship over authenticated TLS to a managed log store. Stream labels segregate environments (staging / production), workload roles, and instance identifiers so logs from different tenants and workloads remain queryable without cross-contamination. Metrics ship via the same authenticated transport.

7. BYOK & customer keys

Bring Your Own Key (BYOK) keeps your AI-provider prompts flowing through accounts that you control. Your key is sealed at the point of submission via AES-256-GCM with the row's id as additional authenticated data (AAD) — copying ciphertext to a different row makes it undecryptable. The plaintext key is materialised only in the worker's per-request memory; never logged, never persisted in cleartext.

You can rotate or revoke a BYOK key from /app/account at any time.

8. Vulnerability disclosure

Report vulnerabilities to security@trendvidia.com. We commit to:

• Acknowledge receipt within 2 business days.
• Provide a triage status within 5 business days.
• Work toward remediation in coordination with the reporter, with a 90-day disclosure window by default.
• Credit reporters who request it in the eventual public advisory.

We don't run a paid bug-bounty program today. Out-of-scope: denial-of-service, social engineering of staff or customers, physical attacks against TrendVidia property, and findings derived from violating the Terms (e.g. abusing another account, mass scanning).

9. Incident response

Production incidents follow an internal runbook covering detection, triage, mitigation, and customer communication. For incidents that affect customer data confidentiality or integrity, we notify the affected billing contacts without undue delay and within the timeframes required by applicable law (e.g. GDPR Article 33: 72 hours).

10. Compliance posture

We are not currently certified under SOC 2, ISO 27001, HIPAA, FedRAMP, or PCI DSS. We do not handle payment-card data — all cardholder data is processed by a PCI DSS compliant payment provider on our behalf.

We've built Steward against the controls those frameworks expect (encryption, audit, RBAC, least privilege, incident response, vulnerability management). If your procurement process needs a specific attestation we don't hold yet, contact security@trendvidia.com so we can scope what a customer-driven engagement would look like.

11. Contact

Security disclosures: security@trendvidia.com. For sensitive reports, request our PGP key in your initial email and we'll provide it before you send details.