Security model
Magmell treats handler code and its inputs as workload data. Authentication, team scoping, secret delivery, and sandbox boundaries are enforced by the platform rather than left to each handler.
Authentication and teams
Section titled “Authentication and teams”User sessions use short-lived access tokens and a rotating refresh session. API keys use the
smk_ credential format and belong to one team. Requests are scoped to the authenticated team;
resources from another team are not exposed through lookup behavior.
Use user credentials for account and membership administration. Use a team API key for servers, CI, and application integrations.
export MAGMELL_BASE_URL=https://api.magmell.siloga.cloudexport MAGMELL_API_KEY=smk_...Never embed an API key in browser code or a deployed handler.
Secret isolation
Section titled “Secret isolation”Deployment secrets are encrypted at rest. For a run, the gateway decrypts the selected deployment’s
set and delivers it in the invocation channel. The runtime scopes it to that invocation through
siloga_agent.secret() or the TypeScript Agent SDK’s secret() rather than exposing it in the
process environment.
Execution isolation
Section titled “Execution isolation”Production handlers run in isolated sandbox environments. The control-plane API and backing services are not exposed to those sandboxes. Internet access is controlled by the platform environment; do not assume a handler can reach private infrastructure.
Build inputs
Section titled “Build inputs”The build accepts validated source trees for Python 3.12 and policy-gated Node.js 22,
runtime-specific locked dependencies, and ordered setup steps, under either the handler or the
command preset. Absolute paths, traversal, runtime-owned paths, and credential-like files are
rejected. A command deployment additionally supplies an exact entrypoint argv, which is validated
against a fixed length and character contract and is never shell-interpreted. Setup steps execute as
trusted build commands with administrative build privileges and may install operating-system packages
or prepare files in /app. The resulting deployment runs under the platform runtime identity.
Build networking is controlled by the execution environment; a per-domain build egress allowlist is not currently supported. Deployment secrets are unavailable during the build.
Treat dependencies as part of the deployment’s trusted code. Pin versions and review updates before building a new release.
Webhook targets
Section titled “Webhook targets”A service’s webhook URL is checked when it is configured and again before every delivery.
Only https:// targets on public addresses are accepted; targets resolving to private,
loopback, link-local, metadata or other special-use addresses are rejected, and redirects
are never followed. Because deliveries use TLS with certificate verification, a target that
later resolves to an internal address cannot receive a payload: the handshake fails before
any bytes of the report are sent. Response bodies are never read.
Your responsibilities
Section titled “Your responsibilities”- Keep user credentials and API keys out of source control.
- Give automated systems their own named team keys and revoke unused keys.
- Avoid placing sensitive data in run input, result, or structured events.
- Validate external inputs inside your handler.
- Make retried handlers and webhook receivers idempotent.
- Pin and review third-party dependencies.