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() 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 handler preset accepts flat filenames, the Python 3.12 runtime, requirements, and ordered setup
steps. Paths and custom command entrypoints are not accepted. Setup steps execute as trusted build
commands with administrative build privileges and may install operating-system packages or prepare
files in /app. The resulting handler 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”Webhook URLs are checked both when a run is created and again before delivery. Targets resolving to non-public addresses are rejected, and redirects are not followed, reducing server-side request forgery risk.
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.