Security model

Trust boundary

This first release is for a trusted team and a trusted Docker host. The web catalog can run without Docker. Management listens on the loopback interface, requires TLS 1.3 and authenticates each request using an individual bearer credential. For a remote demo, use SSH port forwarding and verify the hub's certificate. The optional public storefront handles discovery, invited Google accounts and test-mode billing on a separate process. The managed control plane remains private and single-host.

A private deployment separates its worker containers and API access from other ordinary members. A shared deployment allows authenticated members to invoke its published tools. The creator or an administrator controls removal. Keep your key out of URLs, browser storage, screenshots and support tickets. Revocation prevents future requests; it cannot recall results already delivered. The host administrator and the code of a tool you invoke can access its input and output.

Storage and transport

The hub encrypts its deployment journal, uploaded source/archive and review records with AES-256-GCM. Authentication keys and the TLS private key bootstrap this protection and live in operator-owned private files. The host's filesystem and backup access remain security boundaries. Keep the state key separately when backing up ciphertext. Do not initialize two controllers over copies of the same live Docker state.

Tool call bodies and results are not written to the hub journal. Processes handle plaintext while executing. Admitted OCI image layers can remain in the Docker daemon's image store; operators should use encrypted disks and protected backups. The UI keeps authentication material in memory for the current page. Do not embed third-party credentials or private records in uploaded images.

Uploaded code

Upload stores an immutable Python source or a validated single-image archive. It does not run code at upload time. An operator must check the original bytes against the submitted SHA-256, inspect the implementation and review its declared tool schemas before approving that exact package. Metadata and tool descriptions supplied by users are untrusted text. Admission is a human trust decision, not a malware detector.

Approved replicas run as a non-root user under a fixed profile. The hub controls the entrypoint, denies host mounts and network access, drops capabilities, sets no-new-privileges and enforces CPU, memory and PID limits. A Docker container shares its host kernel. Use a dedicated isolated host for workloads you do not trust; ordinary containers do not provide a hardened public arbitrary-code service.

Limits and recovery

The scheduler reserves capacity against the entire hub, including private instances, before adding a worker. The effective limit is the smallest of the replica cap, CPU budget divided by per-replica CPU, and memory budget divided by per-replica memory. Refuse a request if allocating its worker would exceed that limit. Operational uncertainty must fail closed. A stop or recovery may remove only the verified resources owned by the instance. No workflow provisions paid cloud machines.

If you suspect a leaked caller key, revoke it, review affected private instances as the administrator and issue a fresh key. Use a private channel to report vulnerabilities to the repository owner; do not include keys, uploaded packages, queries or personal data in public issues.

Public storefront

The optional public account process trusts a TLS proxy on its loopback socket at one configured Host. It serves public discovery metadata and an invited account console. It does not mount a Docker socket, accept operator keys or register management APIs. Restrict local process access at the host boundary. Google sign-in verifies the issuer, audience, signature and a one-time browser-bound state, PKCE and nonce. Only an explicitly mapped subject can sign in. A member with account-console administration has no container administration grant.

Billing accepts a Stripe test secret, validates a fixed monthly price and records authenticated, matching test invoice notices. Browser redirects, client-side input and invoice receipts cannot grant worker capacity. Protect the provider configuration, ledger key and encrypted journal separately. Treat the TLS edge's logs, forwarding rules and abuse controls as part of deployment configuration.