Your customers have their own view of this model. Share the Customer Security Model with their security teams during procurement. It covers the same architecture from their perspective.
The Trust Boundary
| Party | Runs | Can see | Cannot see |
|---|---|---|---|
| Tensor9 | Management plane | Deployment coordination metadata, platform health | Your code, customer data, any credentials |
| You (vendor) | Control plane (in your AWS account) | Deployment status, health, logs/metrics/traces, secret existence | Secret values, customer application data, customer infrastructure credentials |
| Your customer | Application environment (in their account) | Full audit log of all vendor activity, their own data, access control settings | — |
Data Sovereignty
Your customers’ data never leaves their environment. This is enforced by architecture, not policy. Your software is deployed into the customer’s account or datacenter. Their data, credentials, and secrets stay inside their boundary. Your control plane receives deployment metadata (status, health, version state) but never application data or credentials. Tensor9’s management plane sees even less: only the coordination metadata needed to orchestrate deployments. It has no access to your application code, your customers’ data, or anyone’s credentials.Customer isolation
Each of your customers gets a fully isolated environment:- Their own controller instance
- Their own application deployment
- Their own infrastructure (AWS account, datacenter, or cluster)
- No network connectivity to any other customer’s environment
Connectivity and Identity
Customer environments never accept inbound connections, not from you and not from Tensor9. The appliance in each customer’s environment initiates all communication outbound over mutual TLS, using a unique per-appliance certificate that rotates monthly. Your customers choose the network transport (public HTTPS, AWS PrivateLink, or Tailscale). New appliances authenticate using platform-native identity (AWS STS, GCP JWTs, or Kubernetes OIDC). There are no pre-shared secrets to distribute. See Connection Security for the mTLS protocol, certificate lifecycle, and bootstrap process. See Connectivity for transport options and network architecture.Permissions
Your access to each customer’s environment is scoped into phases: Install, Observe, Deploy, and Operate. Steady-state access is read-only. Elevated access for deployments and operations is time-bounded and requires customer approval. Explicit deny statements prevent destructive actions regardless of phase. Your customers can disable or revoke any permission tier at any time. Changes take effect immediately. See Permissions Model for the full phase breakdown and IAM implementation. See Revoking Access for step-by-step instructions your customers can follow.Secrets
Your customers create and manage their own credentials in their own infrastructure: Kubernetes Secrets, AWS Secrets Manager, or SSM Parameter Store. You never handle their secrets. The controller detects configured secrets automatically without viewing, transmitting, or storing actual values. See Secrets for the vendor-side configuration model. See Credentials and Secrets for the customer-facing documentation.Customer-Provided Services and Ingress
Your customers can substitute Tensor9-managed service equivalents with their own existing databases, message queues, and search engines. They use their own backup policies, patch schedules, and security controls. They also choose how end users access the deployed application: public, IP allowlist, or private network via Tailscale. The same application compiles differently based on their selection. No code changes required on your side. See Customer-Provided Services for supported services and configuration. See Ingress Control for available postures.Audit and Transparency
All vendor activity in customer environments is logged on both sides. Customer-side logging uses their existing tools: CloudTrail, Cloud Audit Logs, or Kubernetes audit. Your control plane maintains its own audit trail. For remote operations, Tensor9 adds a cryptographic signing chain. Customers authorize commands with their own key, the appliance signs output, and the resulting manifest is independently verifiable by either party. See Operations Security for the signing protocol and verification commands.Tensor9’s Security Posture
Tensor9 is SOC 2 Type II certified. An independent auditor observed our controls over a sustained period and confirmed they work as designed. The report covers access management, change management, incident response, availability, data protection, and vendor management. Existing customers and prospects can request a copy by contacting us.What to Share with Your Customers
When your customers’ security teams evaluate your self-hosted offering, point them to these pages. They describe the same architecture covered here, written for the customer’s audience:- Security Model - the trust boundary from their perspective
- Permissions - what the controller can and cannot do
- Revoking Access - how to disable or revoke access
- Credentials and Secrets - how secrets are handled
- Connection Security - mTLS, certificate lifecycle, and bootstrap