Documentation/FoundationsDownload prototype ↓

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.