Are you an LLM? You can read better optimized documentation at /docs/agent-guard/custom-runtimes/limitations.md for this page in Markdown format
Limitations
Some boundaries that apply to other agent artifacts, or that you might expect of a container, do not apply to a custom runtime.
The image is not admission-checked
The agent definition is admission-checked: signature verification with --pub-key and ArtifactPolicy both apply to it, as do its MCP, skill, and policy modules. The image named in spec.framework goes through neither. Agent Guard resolves it to a digest, checks its platform, command, and version label, and runs it.
The definition is the control. Whoever can change the image reference in an admitted definition, or push a new image to a tag the definition names, decides what runs. Pin the image by digest in the definition (...@sha256:...) so that an admitted definition always runs the image it was admitted with, and sign the definition.
Network reach is the microVM's
The container shares the microVM's network namespace and runs as the agent's account, so the run's allow list applies to it as it applies to an agent CLI. It has no network restriction of its own beyond that. Model and tool traffic goes through the Jozu AI Gateway because that is where the application's credentials and model names work. Any other host the application calls must be on the allow list, in the definition's spec.egress.
What this means: the Jozu gateway protects credentials and governs the traffic that goes through it, and the allow list bounds where everything else can go. Neither inspects what the application sends to a listed host. See How network access works.
No container resource limits
The container has no CPU, memory, or process limits inside the microVM. It is bounded only by the microVM's --vcpus and --ram.
The root filesystem is writable
The container's root filesystem is writable. Changes are discarded when the container exits, but during a session the application can modify its own files.
Only linux/arm64
The microVM is arm64 Linux, so only linux/arm64 images run. An image with no linux/arm64 variant is refused before boot.
Values are delivered as environment variables only
Values reach the application as environment variables only. A need with target: file, or one that uses the file resolver (from.file), cannot be resolved: if it is required, the run stops before the microVM boots; if it is optional, it is skipped.
Models on the host or a private network are unreachable
The Jozu gateway refuses to connect to a model endpoint on a private network address, and an agent definition has no field to allow it. A model served on the machine running Agent Guard, such as Ollama, or on a private network, cannot be named directly as an llm module's source.endpoint.
ModelKit models cannot be served
An llm module cannot use a model packaged as a ModelKit (source.modelkit). The Jozu gateway drops such a module for the session.
One credential per model, for three providers
An llm module names one need as its credential, and only a module whose provider is anthropic, openai, or gemini can declare one. A provider that authenticates with more than one value, such as an access key, a secret key and a region, cannot be configured.
Policy covers only gateway traffic
Policies apply to what passes through the Jozu gateway: model requests and MCP tool calls. An action the application takes directly is outside policy unless the application asks for a decision itself through AGENTGUARD_POLICY_URL, and that decision is enforced only by the application.
Shutdown gives the application 5 seconds
When a session ends, the application gets SIGTERM and 5 seconds before it is killed. The grace period cannot be changed. Write state as you go rather than on shutdown.
The image digest is not in the session record
The session records and fleet heartbeat carry the image reference as written, not the digest it resolved to. The run prints the digest, and the guest checks it, but to know afterwards exactly which image a session ran, pin the digest in the definition.
Some run flags do not apply
--pass-env and --pass-cloud-creds do not reach the application's container. --version and --agent-bin are ignored, and --shell is not supported. See Run and operate a runtime.
