SECURITY / ARCHITECTURE & LIMITATIONS
A defined perimeter.
An honest trust model.
Current status: controlled preview. Rental execution, customer billing, automated network provisioning, and confidential-compute admission are not enabled. The site describes the target architecture, not a deployed end-to-end private GPU network.
1. What runs where
The website, tenant authorization API and assistant orchestration run on Cloudflare Workers. Google Firebase Authentication provides Google and verified email/password identities. The backend verifies identity tokens and creates hashed, expiring server-side sessions. D1 stores workspace membership, rental ownership, proposals, agreements, privacy requests, retained conversation history, drafts and audit records. Cloudflare Workers AI supplies model inference. GPU workloads would run on third-party Vast.ai machines, outside the control-plane provider's physical infrastructure.
The assistant runs a bounded tool-selection loop in the backend. Workspace identity comes from the authenticated session, never model output. Each database query and rental operation is scoped by server-owned membership. No customer agent receives infrastructure credentials or a general-purpose execution environment.
2. Private access is not host confidentiality
Cloudflare Tunnel can provide outbound connectivity and Cloudflare Access can enforce identity policies. Neither removes the GPU host administrator from the trust boundary. A privileged operator may inspect an ordinary container's or VM's memory, disks and credentials. Encrypting a disk does not prevent inspection after it is unlocked.
Private-access admission must verify per-tenant routes and policies, tunnel credential isolation, host configuration, and absence of direct-access bypass. A tunnel alone is insufficient. Workload egress also needs enforcement outside an untrusted container; Cloudflare Gateway does not automatically govern every packet on a Vast host.
3. Confidential admission: evidence before secrets
- Require supported confidential CPU and GPU hardware, firmware, drivers, secure operating modes, and a protected CPU-to-GPU transfer path.
- Validate signed evidence through the appropriate vendor trust chains, with fresh challenges, revocation checks, minimum security versions, and approved boot/workload measurements.
- Bind evidence to the workload's ephemeral public key, its specific CPU/GPU association and current session. A valid report from another device or an old session must not authorize this workload.
- Release short-lived data keys only to the independently verified environment. Keep the key broker outside the GPU provider's and agent's administrative boundary; prefer customer-controlled keys.
- Renew evidence and key leases; reject stale, missing, revoked or mismatched evidence. Key revocation limits future access, but cannot retract secrets already released.
Hardware names, marketplace verification, a host's ISO certificate, and a dashboard badge do not substitute for attestation. No qualifying Vast.ai configuration has been verified for this release. Confidential rentals remain unavailable.
4. Authorization and agent safety
Workspace membership is assigned from a cryptographically verified identity subject, never a caller-supplied tenant ID. Inventory is filtered through server-owned rental records. Customer tools can discover offers, read their inventory and create proposals; they cannot mutate marketplace resources. Tool arguments are schema-validated and cannot select another tenant or arbitrary URL.
The embedded assistant has no administrative, campaign, shell, filesystem or browser tools. Separate owner-authorized APIs can draft structured copy and campaigns; publishing copy requires explicit owner authorization. Campaign delivery is not implemented. Personal external administrative tools are not connected to the embedded assistant.
Prompt instructions are not an authorization boundary. The backend enforces at most three model calls, two tool calls and 512 output tokens per model call, with one active turn per workspace. Customer usage is limited to two messages per minute per workspace and twenty messages per UTC day across the site. Current terms acceptance is required. The model provider processes submitted messages and bounded history; do not submit secrets or sensitive workload data.
5. Production acceptance criteria
| Boundary | Required evidence before launch |
|---|---|
| Commercial & financial | Written resale authorization; customer contracts; payment and refund workflows; atomic credit reservation; metering including storage and transfer; quotas; reconciliation; reliable expiry/termination. |
| Network | Tenant isolation tests, outbound tunnel bootstrap, closed direct ports, access policy tests, credential rotation and host-level bypass/egress assessment. |
| Host | Approved provider registry, region and image policy, lifecycle controls and documented workload classification. |
| Confidential | Independent verifier, attestation-bound key release and negative tests for replay, substitution, stale firmware and disabled security modes. |
| Operations | External immutable audit export, retention policy, incident response, backup/restore drills, penetration testing, abuse response and support ownership. |
6. Residual risk and compliance
No architecture eliminates application vulnerabilities, denial of service, traffic analysis, all side channels or authorized data export. Host-reported utilization is operational telemetry, not cryptographic security evidence. D1 audit entries are not an immutable external audit archive.
ShieldVPC makes no SOC 2, HIPAA, PCI DSS or confidential-computing certification claim. Cloudflare's and providers' certifications do not automatically apply to ShieldVPC. Do not process regulated or highly sensitive data without a documented, independently reviewed deployment and applicable contracts.
References
Vast.ai security FAQ · Cloudflare Tunnel
Security contact: security@shieldvpc.com. Contact mailboxes must be provisioned by the operator before public launch.