Skip to content

Capability types

A capability is a host grant. It tells the runtime what a provider may ask the host to do.

CapabilityMeaningExample
DomainProvider may request HTTPS callouts to an allowed host.api.github.com
Git repoProvider may request a Git tree handoff matching an allowed repo pattern.git@github.com:*
Unix socketProvider may request an exact Unix socket endpoint.Docker daemon socket
Preopened pathProvider receives an explicit WASI filesystem preopen.db provider /data read-only preopen
Auth injectionHost may inject a credential into requests for approved domains.GitHub Authorization header
Memory declarationProvider manifest declares expected memory need.memoryMb: 128
Blob byte limitsProvider manifest declares fetch/read blob byte ceilings.fetchBlobBytes, readBlobBytes

Memory declarations should not be documented as enforced long-lived provider memory limits unless runtime enforcement is added and tested. They are still useful manifest data.

The host checks HTTP callouts before dispatch:

  • HTTPS requires an allowed host. Built-in manifests should use exact host grants; the runtime checker also supports an explicit * wildcard grant.
  • Plain HTTP is denied.
  • Literal private and link-local IP targets are denied.
  • Credentials are injected only for manifest-approved auth domains.

This is a capability boundary, not a general proof that every possible DNS trick is impossible.

Unix socket access is exact-path allowlisted. Docker uses this shape.

Treat Docker specially. The socket file may be mounted read-only into the container, but Docker daemon API access remains powerful. Do not present a read-only socket bind as a complete safety boundary.

Preopened paths are explicit local filesystem grants. The db provider preopens the selected SQLite database file’s parent directory read-only as /data, then opens the configured file inside that guest path.

Use this wording: no arbitrary host filesystem access, only explicit WASI preopens.