Tenant isolation
Each customer receives a separate Linux user, home, workspace, runtime state, secrets, service, and browser allocation.
Available now Security without theatre
Control should be part of the product, not a promise.
Principal is useful because it can use tools and complete work. The security model is designed around that reality: separate customer environments, scoped credentials, hard usage limits, approval gates, and temporary support access.
CustomerOwns decisions
↓
Principal control planeIdentity · approvals · lifecycle
↓
Isolated customer tenantWorkspace · tools · business context
Root-owned gatewayScoped model access · quotas
Provider credentials stay outside the assistant
✓Separate tenantPer customer
✓Scoped accessRevocable independently
✓Hard quotasEnforced before provider use
✓Expiring supportCustomer-approved
The control layers
Your assistant gets a workspace, not the keys to the building.
The important boundaries are enforced outside the assistant’s instructions, where they cannot be talked around by a message or prompt.
Credential separation
The assistant receives a revocable internal token. Real provider credentials remain encrypted behind a root-owned gateway.
Available nowHard usage limits
Monthly request quotas, optional token quotas, output limits, and request-size ceilings are checked before provider use.
Available nowApproval gates
Messages, bookings, spending, file sharing, and other important outside actions can be held for the customer.
Available nowLifecycle control
Demo expiry stops the runtime and revokes model access. Destroy removes the service, tenant files, user, and scoped token.
Available nowVerified backups
Runtime state, workspaces, secrets, token registries, and service definitions are included in encrypted daily backups.
Available now Important actions stay human
A normal message cannot create its own permission.
Approval rules are designed so the assistant cannot interpret casual chat as authority for a sensitive action. The workflow shows what is proposed and waits for the correct decision path.
Send a customer emailConfirm a bookingCommit spendingShare a fileChange a business system
Action waitingSend supplier confirmation?
Recipient, draft, and reason are ready to review.
Principal prepares→Owner reviews→Action proceeds
Nothing sent yetWaiting for customer
Support without a standing back door
Help requires your permission and has an end time.
A named support operator requests access to one customer environment for a stated reason and duration. The customer approves through a private flow. The execution host rechecks the grant before every action and rejects it after revocation or expiry.
- Separate Telegram and registered-email verification paths
- Recovery flow when the customer channel is unavailable
- Fixed tenant diagnostics and service controls
- Metadata audit without storing support prompts or customer output
What happens to access
From onboarding to deletion, every stage has a boundary.
Prepare
A credential-free bundle is created and installed in a stopped state.
Personalise
Onboarding answers become managed context and approval rules.
Activate
Scoped provider access and the customer channel are validated before use.
Operate
Quotas, audit metadata, expiry, and support controls remain active.
Destroy
The runtime service, OS user, files, and scoped access are removed.
Honest assurance status
Keep the destination visible. Do not pretend we have already arrived.
Formal assurance is valuable and remains part of the product direction. The status below separates operating controls from planned external validation.
Operating controls
- Customer tenant isolation
- Scoped and revocable provider access
- Hard quotas and audit metadata
- Customer-approved temporary support
- Encrypted operational backups
Privacy and risk review
- Thailand PDPA assessment for local workflows
- Data minimisation and retention decisions
- Extra review for clinics, schools, finance, and children
- Customer-specific approval policy
- Integration credential review
Formal programme
- Documented DPA and privacy pack
- Independent penetration testing
- SOC 2 readiness and audit path
- SSO and SCIM controls
- Advanced retention and export controls
Principal does not currently claim SOC 2 certification, HIPAA compliance, or zero-knowledge hosting. CBS Automate controls the infrastructure root account, and the runtime must decrypt customer data while using it. A customer-controlled hosting and key tier remains a planned stronger option.
Security questions
Clear answers.
Detailed technical material is available during an enterprise review.
Can one customer assistant read another customer’s files?
No by design. Each customer runs as a different non-sudo Linux user with a separate home, workspace, state directory, secrets, service, and protected tenant directory.
Does the assistant receive the real provider API key?
No. It receives a random internal token understood only by Principal’s loopback gateway. The real credential remains root-owned and can be revoked independently.
Can support staff enter the environment whenever they want?
Routine product support uses a named, customer-approved, tenant-bound grant with a stated reason and exact expiry. It is not standing access. CBS Automate still retains host-level break-glass maintenance authority, which is why the service is not described as zero knowledge.
Is Principal certified for regulated data?
Not today. Sensitive deployments require a separate risk and privacy review. Formal assurance, independent testing, and advanced enterprise controls are planned rather than presented as completed certifications.
Can a customer environment be removed?
Yes. The destroy lifecycle removes the tenant service, OS user, tenant files, and scoped model token while preserving the minimum operational audit required by the control service.
Security questions should improve the design.
Tell us what data, people, actions, and systems the workflow would touch. We will explain the current control, the gap if one exists, and what must be added before launch.