SOC 2 readiness and security posture
TensorCost is built and operated by Vaadhlabs. This page describes our customer-facing security posture: the controls in place today, the compliance certifications on our roadmap, and the architecture details an enterprise security reviewer cares about.We are not yet SOC 2 certified and have not yet completed an independent penetration test. Both are on our roadmap; neither has a committed completion date we can publish yet. A trust portal is planned but not live — for now, request our current security posture directly via security@tensorcost.com.
Compliance posture at a glance
Trust service criteria — what we have, what’s in flight
Security (mandatory)
In place:- Multi-tenant Row Level Security on Postgres. 21 tables enforced today, target 50; rolling out wave-by-wave with a
runAsBypassdiscipline lint. See the RLS architecture below. - JWT auth with refresh tokens; Cognito federation for browser SSO; SAML / OIDC for enterprise SSO.
- Three built-in roles (
member,admin,owner); RBAC primitive shared across REST, gRPC, and MCP. - HMAC-SHA256 + Redis nonce replay for every agent gRPC stream (see agent ingress).
- TLS 1.3 in transit for every customer-facing endpoint (REST, WS, gRPC).
- AES-256 encryption at rest (RDS, S3, EBS); per-tenant KMS-derived keys for sensitive credential storage.
- AWS STS AssumeRole + external ID for cross-account reads; 15-minute temp credentials, never persisted.
- Read-only IAM on customer accounts. No
bedrock:Invoke, nos3:Put, nologs:Putanywhere. - Customer-owned S3 buckets for raw Bedrock invocation logs. We never copy raw logs to our account.
- Redaction at ingestion — raw prompts and responses are hashed; only hashes enter
ai_spend_events. See redaction at ingestion. - Rate limiting at the gateway and per-tenant on the gRPC ingress.
- CloudTrail, GuardDuty, AWS Config enabled across the platform AWS organization.
- Dependabot, secret scanning, required PR reviews + status checks on every repo.
- A public trust portal (not live yet).
- Per-tenant gRPC token-bucket rate limit.
- mTLS upgrade path for the agent ingress (post-Envoy migration).
- AI-service RLS rollout (next wave: 17 tables across the
ai.*schema).
Availability
- RDS Multi-AZ with automated backups (35-day retention).
- Redis ElastiCache cluster mode with replicas.
- ALB cross-zone load balancing; NLB targets in three AZs.
- Per-region deployment in
us-east-1(default), with EU-region rollout planned. - A public status page is planned but not live yet; ask support for current uptime data in the meantime.
- Documented incident response procedure with PagerDuty rotation.
Confidentiality
- All tenant data scoped by
tenant_idand enforced by RLS. - Sensitive config values (webhook URLs, routing keys, cloud credentials) encrypted at the column level using a per-tenant KMS-derived key. Surfaced as masked values in API responses; full values only via
decrypt-scoped endpoints. - Customizable data retention (30–365 days for raw metrics; 90–730 days for recommendations; 7 years for audit).
- Tenant offboarding flow with 30-day soft-delete; hard delete preserves audit-trail rows. See tenant offboarding.
- NDA template signed by every employee and contractor with production access.
Processing integrity
- Analysis audit log captures every anomaly-detection decision: baseline statistics used, current value, each method’s score, composite confidence, classification.
- Inference feedback records every recommendation outcome (accepted / rejected / modified) with reason + post-action measurements; feeds back into ML training.
- Action queue tracks every enforcement action through pending → approved → executing → completed/failed with full audit trail.
- Event persistence via the event store (ADR-0011) — cross-instance durable event ledger.
- Daily ingest reconciliation — agent-emitted vs backend-received counts, with a delta alert.
Privacy
- Privacy policy and DPA template on request.
- Personal data collected: email, name, IP / user-agent on auth, timezone preference.
- Subprocessor list available on request and republished annually.
- Cookie policy on the marketing site.
- DSAR process documented; DSARs handled within 30 days.
Multi-tenant RLS
Every customer is a tenant; every row in every table that holds tenant data carries atenant_id column and is protected by Postgres Row Level Security.
app.tenant_id per request via a Sequelize hook; cross-tenant reads are unreachable by construction. The only path that bypasses RLS is runAsBypass(tenantId, fn) from @tensorcost/db-utils, used by:
- gRPC handlers (after the agent’s
tenantIdis verified by HMAC). - Cron-driven sweeps (anomaly detection, recommenders).
- Cross-service joins.
RUN-AS-BYPASS-LINT rule is on the way; until then, code review enforces the discipline. A botched RLS migration silently returns zero rows, which during a customer demo is indistinguishable from a feature that “doesn’t work” — so each table’s rollout requires both the migration and a wrap+verify pass on every reader before merge.
Agent ingress
Where a customer opts into the gRPC transport (see agent installation), the unified GPU agent connects to TensorCost over a long-lived gRPC stream on TCP/50051, fronted by an AWS Network Load Balancer with TLS-only listeners. The task security group accepts0.0.0.0/0 on TCP/50051; four compensating controls make this safe:
The escape hatch
GPU_GRPC_ALLOW_UNREGISTERED_AGENTS=true was removed; every agent must carry a verified hello.
Redaction at ingestion
Raw prompts and responses never enter our storage.- Bedrock invocation logs are read read-only from customer-owned S3 buckets (or CloudWatch Logs).
- The ingestion parser computes
prompt_hashandresponse_hash(SHA-256) and writes those. - Unit tests assert no raw prompt or response text escapes the parser.
- Customers concerned about content can disable request-metadata capture entirely and still receive model/cost/latency-level attribution and recommendations.
- Anonymized aggregates that feed our public benchmark report are gated behind explicit per-tenant consent.
Customer onboarding — least-privilege IAM
The CFN onboarding stack ships with the minimum read-only IAM policy required. Modes:
Variants supported in the wizard:
- Consolidated billing with separate payer — payer-account CUR read + member-account Bedrock log read.
- SCP-restricted environments —
RolePathPrefixparameter for Organizations that mandate a custom path. - AWS Control Tower / Landing Zone — defaults to
AWSControlTowerExecutionjump role. - Cross-account CUR — separate bucket-policy snippet shipped as a distinct artifact (security teams routinely review these independently).
Secret rotation
Per the secret-rotation runbook, all platform secrets rotate on a documented cadence:
Customer-facing secrets (agent HMAC keys, OpenAI API keys we hold, etc.) are stored encrypted with a per-tenant KMS-derived key in
integration.connection_secret (RLS-enforced).
Tenant offboarding
A documented state machine —active → offboarding_pending → offboarding_archive → deleted — covers every churn or GDPR Art. 17 request:
- Soft delete (30 days) — tenant moves to
offboarding_pending. Ingestion stops, dashboards become read-only, recommendations freeze. Data is retained for 30 days to allow recovery. - Archive (7 days) — tenant moves to
offboarding_archive. A signed export bundle (CSV + JSON) is delivered to the tenant’s offboarding contact. - Hard delete — every tenant-scoped row is purged via chunked DELETE per schema (large schemas like
ai.ai_spend_eventsare deleted in batches to avoid bloat). Customer-owned S3 buckets are not touched — those are the customer’s to manage. - Audit-trail preservation —
audit.*rows survive offboarding indefinitely; required for compliance and legal-hold preservation.
Penetration testing
We have not yet completed an independent penetration test. An annual cadence with independent third-party testers, plus targeted testing on major releases, is the plan once we run the first one — there’s no executive summary to share yet.Background checks and security training
- Background checks on every team member with production access.
- Annual security awareness training (KnowBe4) for all staff.
- Quarterly tabletop incident-response exercises.
What an enterprise prospect typically asks for
- Security questionnaire (SIG / CAIQ) — completed on request, typically 48–72 hours.
- Architecture diagrams at three levels (exec, platform-lead, security-reviewer). Available on request.
- Subprocessor list and DPA. Available on request.
- SOC 2 bridge letter — not applicable yet; we haven’t started the audit.
- Penetration-test executive summary — not applicable yet; no test has been completed.
- Sample audit-trail export — under NDA.
Reporting a vulnerability
Please report suspected vulnerabilities by emailing security@tensorcost.com. Include:- A description of the issue and potential impact.
- Reproduction steps (PoC, logs, screenshots).
- Affected versions / commit hashes.
- Suggested mitigations if any.