Runtime isolation

Treat model packages as untrusted inputs

Even internally produced candidates can contain malformed artifacts, unsafe serialized objects, vulnerable dependencies, or unexpected resource behavior. Third-party models add provenance and supply-chain risk. Isolation is a default, not a response to detected malice.

Isolation controls

• dedicated process or container identity per package or trust tier;
• read-only model files and immutable runtime image;
• no host filesystem access beyond declared mounts;
• outbound network denied by default;
• explicit tool allowlist with argument validation;
• CPU, GPU, memory, disk, output, and wall-clock ceilings;
• syscall and device restrictions where supported;
• short-lived credentials scoped to one task;
• encrypted temporary storage with secure cleanup;
• request and response size limits;
• package digest and signature verification before load.

Separate build, evaluation, and serving

Candidate generation may require compilers or training frameworks that production serving does not. Use different images and credentials. An evaluation worker needs hidden test access that the candidate runtime must not receive. Production serving should contain the smallest possible dependency set.

Tool mediation

Models never call operating-system or network tools directly. They emit structured requests to a mediator that validates capability, schema, policy, and user approval.

FUNCTION execute_tool_request(model_id, task, tool_request)
    ASSERT tool_request.schema_valid
    ASSERT tool_request.tool IN task.allowed_tools
    ASSERT tool_request.arguments SATISFY tool_policy
    ASSERT model_id HAS_CAPABILITY(tool_request.tool)

    IF tool_request.risk_tier >= HUMAN_APPROVAL_TIER
        approval <- REQUEST_HUMAN_APPROVAL(tool_request)
        REQUIRE approval.granted
    END IF

    RETURN RUN_TOOL_IN_SEPARATE_SANDBOX(tool_request)
END FUNCTION

Resource exhaustion

Enforce hard ceilings outside the model process. Detect repeated near-limit behavior and downgrade eligibility. A model that is accurate only when allowed unbounded context or retries does not satisfy a constrained contract.

Secrets

Prefer capability tokens over general credentials. Never place secrets in prompts or model-accessible environment variables. Redact logs and ensure generated outputs cannot cause downstream secret interpolation.

Failure behavior

Timeout, crash, invalid output, and resource limit events should produce typed errors. The router can use approved fallbacks. It must not retry indefinitely or expand permissions to “help” a failing model.