FOUNDATIONS / DESIGN PARTNER PREVIEW
Authority stays with the host.
The tested boundaries, their limits, and the work required before production use.
What the prototype enforces
- Caller identity: two bearer tokens map to tenants on the server. A request cannot choose another tenant by changing its payload.
- Data scope: database queries include the authenticated tenant.
- Tool inputs: generated code receives an input snapshot, not the database binding.
- Egress: the tool loader sets
globalOutbound: null. - Execution limits: the fixture configures CPU and subrequest limits.
- Revocation: disabled tools are rejected before new execution.
What types cannot enforce
A type-checked program can still request excessive authority. A read-oriented SDK facade can still expose a more powerful underlying binding. Least privilege must be enforced by the host, runtime and provider credentials; it cannot be inferred from TypeScript alone.
Before using real customer data
The preview needs production identity and membership, tenant-scoped capability grants, an audit trail, retention and deletion controls, secret management, and independent isolation testing. The current two-token fixture is not a production authentication system.
Infrastructure authority
The experimental controller accepts a Cloudflare credential from its caller. It was deployed temporarily and deleted after testing. It is not suitable as a shared service. A managed controller must validate a caller’s requested changes against separately configured authority and resource limits.
Recovery and destructive actions
Effect retries do not create durable execution. A create request can succeed at the provider and lose its response. A controller needs a recovery strategy that finds the existing resource instead of creating a duplicate. Data deletion and resource teardown also need distinct policies.