Mandrel CLI
The Mandrel CLI (mandrel-cli) is the essential toolchain for agent developers. it provides the necessary commands to validate Mandrel Specifications and generate the deployment artifacts required for the Mandrel mesh.
Installation
The CLI is written in Go and can be installed directly from the source:
go install gitlab.com/the-mandrel-project/mandrel-cli/cmd/mandrel-cli@latest
Primary Commands
1. validate
Performs deep static analysis of your agent’s specification. it checks for schema compliance, semantic consistency, and security best practices.
mandrel-cli validate agent-spec.yaml
What it checks:
- Schema validity against the Mandrel v1.0 standard.
- Required identity claims (Nested JWT/DPoP).
- Governance matrix thresholds and actions.
- Egress/Ingress network allow-lists.
- Delegation controls (
max-fan-out,max-delegations).
Diagnostic codes emitted by the built-in validator:
| Code | Severity | Field | Condition |
|---|---|---|---|
| E001 | Error | metadata.name | Name is absent |
| E002 | Error | spec.runtime.timeout-seconds | Value < 0 |
| E003 | Error | spec.runtime.max-hops-allowed | Value < 0 |
| E004 | Error | spec.governance.enforcement-matrices[*].tiers[*].limit | Threshold tier missing limit |
| E005 | Error | spec.governance.enforcement-matrices[*].tiers[*].match | Category tier missing match |
| E006 | Error | spec.extensions.<key> | Extension key not claimed by any validator (Default-Deny) |
| E007 | Error | spec.extensions.<key> | A third-party validator claims a key under the reserved mandrelproject.ai/ prefix |
| E010 | Error | spec.runtime.max-fan-out | Value < 0 |
| E011 | Error | spec.runtime.max-delegations | Sub-field < 0, or per-session < per-turn |
| E012 | Error | spec.token-budget | primary-chips < 0.1; resolution-chips set and < 0.1; model-id empty; resolution-chips ≥ primary-chips; hold-strategy: warm-estimate without outbound clamp-point |
| E013 | Error | MandrelChipRateTable.spec | Duplicate model-id in rates; baseline.model-id not in rates; input-multiplier or output-multiplier ≤ 0 |
| E030 | Error | spec.network.*-spiffe-* | Workload reference is not a path, a spiffe:// id, or a tag: |
| W030 | Warning | spec.network.*-spiffe-* | Reference names a trust domain explicitly |
| E020 | Error | spec.orchestrator.scope-rejection-policy | Value not in {deny, escalate, transfer} |
| E021 | Error | spec.orchestrator.permitted-delegates[n] | capability absent; risk-profile not in {safety-first, balanced, efficiency-first}; or agents present but empty |
| E022 | Error | spec.orchestrator.planning-depth | Value present and < 1 |
| E023 | Warning | spec.orchestrator.permitted-intents[n].name | Intent name has no matching entry in spec.capabilities.intents |
| E024 | Error | spec.orchestrator.context-trust.session-history | Value not in {full, intents-only, none} |
| E025 | Error | spec.orchestrator.autonomy.* | Autonomy field value not in {autonomous, challenge, deny} |
| W012 | Warning | spec.token-budget.model-id | Model ID not found in the active ChipRateTable (only emitted when --metrology-lab is set) |
| W021 | Warning | spec.orchestrator.autonomy.scope-expansion | scope-expansion is not deny — any runtime scope expansion requires a valid Override Token |
On E030 and W030
A malformed workload reference can never match anything, so an ingress list containing one silently denies callers and an egress list containing one silently permits nothing. Neither is visible without the check, which is why it is an error rather than a warning.
W030 is a warning rather than an error because an absolute reference is legitimate — it names
a workload in a foreign trust domain. But it asserts a SPIFFE federation relationship that only
the platform can confirm, and it ties the spec to one deployment. Authors reach for the
absolute form out of habit from when the trust domain was written into every spec, so the
diagnostic suggests the path-only equivalent. See
Naming a workload.
When --metrology-lab <url> is provided, validate performs a live check of model-id against the lab’s ChipRateTable (GET /v1/chip-rates/models/{model-id}). Without this flag the W012 check is skipped.
2. auth
Manages credentials for the Metrology Lab.
Google IAM Authentication (Zero-Friction)
The google authentication method leverages your existing Google Cloud session (via gcloud or ADC) to provide identity tokens directly to the Metrology Lab. This removes the need for manual OAuth flows or managing your own Client IDs.
How it works:
- Set
auth_method: "google"in your config (or setMANDREL_AUTH_METHOD=google). - Ensure you are logged into Google:
gcloud auth login. - The CLI will automatically call
gcloud auth print-identity-tokenwith the configuredaudiencewhenever a token is needed.
Requirements:
- The
gcloudCLI must be installed and in yourPATH. - The
audiencein your config MUST match the expected audience of the Metrology Lab.
OIDC Authentication (Standard)
The default oidc method uses the standard OIDC Device Authorization Flow. This is suitable for non-Google providers or when gcloud is not available.
auth login
mandrel-cli auth login \
--issuer https://accounts.google.com \
--client-id your-google-client-id \
--client-secret your-google-client-secret \
--audience mandrel-metrology-lab \
--scopes "openid profile email"
Launches the OIDC device authorization flow (RFC 8628). On success, stores the token at ~/.mandrel/credentials. All agents and platform subcommands load this token automatically.
Authentication Flags:
--issuer: The OIDC provider URL (e.g.https://accounts.google.com).--client-id: (Required) The OAuth 2.0 Client ID for the device flow.--client-secret: (Optional) The OAuth 2.0 Client Secret, if required by your provider.--audience: The expected token audience for the Metrology Lab.
The MANDREL_METROLOGY_ISSUER, MANDREL_METROLOGY_CLIENT_ID, and MANDREL_METROLOGY_AUDIENCE environment variables provide defaults for these flags.
auth logout
mandrel-cli auth logout
Removes stored credentials from ~/.mandrel/credentials.
auth status
mandrel-cli auth status
Prints the current token subject, expiry, and scopes.
Configuration
The CLI supports a global configuration file at ~/.mandrel/config.yaml to store common settings and control global behavior.
Global Configuration File
# ~/.mandrel/config.yaml
# Connection settings
metrology_lab_url: "https://lab.mandrel.internal:8740"
auth_method: "google" # Options: oidc, google
issuer: "https://accounts.google.com"
client_id: "your-client-id-here"
client_secret: "your-client-secret-here"
audience: "mandrel-metrology-lab"
# Operational behavior
strict: false
allow_unclaimed_extensions: false
# Plugin management
no_plugins: false
plugins: ["plugin-a", "plugin-b"]
plugins_dirs: ["/opt/mandrel/plugins"]
ignore_plugin_failures: false
plugin_signatures: "ignore" # Options: ignore, warn, require
Configuration Precedence
The CLI resolves settings using the following precedence:
- Command-line Flags (Highest)
- Environment Variables
- Configuration File
- Defaults (Lowest)
Environment Variables
| Config Key | Environment Variable |
|---|---|
metrology_lab_url | MANDREL_METROLOGY_LAB |
issuer | MANDREL_METROLOGY_ISSUER |
audience | MANDREL_METROLOGY_AUDIENCE |
auth_method | MANDREL_AUTH_METHOD |
client_id | MANDREL_METROLOGY_CLIENT_ID |
client_secret | MANDREL_METROLOGY_CLIENT_SECRET |
strict | MANDREL_STRICT |
allow_unclaimed_extensions | MANDREL_ALLOW_UNCLAIMED_EXTENSIONS |
no_plugins | MANDREL_NO_PLUGINS |
plugins | MANDREL_PLUGINS (comma-separated) |
ignore_plugin_failures | MANDREL_IGNORE_PLUGIN_FAILURES |
plugin_signatures | MANDREL_PLUGIN_SIGNATURES |
Custom Config Path
You can override the default configuration location using the --config flag on any command:
mandrel-cli --config /path/to/custom-config.yaml agents list
3. agents
Manages agent card registration and promotion with the Metrology Lab. All subcommands read the lab URL from MANDREL_METROLOGY_LAB by default; --metrology-lab <url> overrides it.
agents register
mandrel-cli agents register --file finance-agent.yaml \
--metrology-lab https://lab.mandrel.internal:8740
Submits the spec to the lab for registration. Re-registration overwrites the existing card; any existing Realized Spec is not automatically revoked.
agents promote
mandrel-cli agents promote finance-specialist \
--metrology-lab https://lab.mandrel.internal:8740
Runs the promotion gate on the registered agent. Returns the promoted MandrelSpec with a status block on success, or a rejection with L-code diagnostics on failure.
agents status
mandrel-cli agents status finance-specialist \
--metrology-lab https://lab.mandrel.internal:8740
Prints the current registration phase (pending, approved, rejected, or revoked) and the promotion timestamp if approved.
agents list
mandrel-cli agents list --metrology-lab https://lab.mandrel.internal:8740
Lists all registered agents visible to the caller’s token.
agents realized
mandrel-cli agents realized finance-specialist \
--metrology-lab https://lab.mandrel.internal:8740
Fetches the baked JSON Realized Spec for an approved agent. This is the exact artifact the Collet fetches at startup.
agents delete
mandrel-cli agents delete finance-specialist \
--metrology-lab https://lab.mandrel.internal:8740
Removes the agent registration and marks any existing Realized Spec as revoked.
4. platform
Administers platform-wide governance and reference data. Requires mandrel:lab:admin scope.
platform policy get
mandrel-cli platform policy get > policy.yaml
Fetches the active MandrelPlatformPolicy.
platform policy put
mandrel-cli platform policy put policy.yaml
Atomically replaces the platform policy. This affects all subsequent agents promote calls.
platform chip-rates get
mandrel-cli platform chip-rates get > rates.yaml
Fetches the active MandrelChipRateTable.
platform chip-rates put
mandrel-cli platform chip-rates put rates.yaml
Atomically replaces the chip rate table.
5. generate
Transforms your declarative spec into production-ready infrastructure-as-code (IaC) artifacts.
# Local mode: generate from a local file
mandrel-cli generate agent-spec.yaml ./dist
# High-Assurance mode: generate from a Lab-approved Realized Spec
mandrel-cli generate --realized finance-specialist ./dist
Generated Artifacts:
- Kubernetes Manifests: Deployment and Service configurations with integrated Collet sidecar.
- NetworkPolicy: K8s-native egress controls derived from the spec’s
networkblock. - OPA Rego Policies: Compiled governance rules to be loaded by the Collet/OPA engine.
Common Flags
| Flag | Default | Meaning |
|---|---|---|
--strict | false | Escalate warnings to errors |
--allow-unclaimed-extensions | false | Downgrade Default-Deny for unclaimed spec.extensions keys to warning |
--no-plugins | false | Skip all subprocess plugin discovery |
--plugin <name> | (all) | Run only the named subprocess plugin (repeatable; built-ins always run) |
--plugins-dir <path> | (none) | Additional plugin discovery directory (repeatable) |
--ignore-plugin-failures | false | Demote plugin errors to warnings |
--plugin-signatures | ignore | Posture for plugin binary signatures (require|warn|ignore) |
Plugin Management
plugins list
Lists all discovered subprocess plugins with their kind, version, and path.
mandrel-cli plugins list
plugins doctor
Runs discovery and reports the health of each plugin (manifest validity, compat string, owned extensions).
mandrel-cli plugins doctor
Plugin Extensions
Plugins can attach custom configuration blocks to a Mandrel Spec under spec.extensions. Each top-level key must be claimed by a registered validator plugin; unclaimed keys block generation by default. Pass --allow-unclaimed-extensions to downgrade this to a warning.
See the Extensions Reference and the full plugin protocol for details on writing validator and generator plugins in Go or any language.
Lifecycle Workflow
graph LR
A[Write Spec] --> B[mandrel-cli validate]
B --> C[mandrel-cli generate]
C --> D[Deploy to K8s]Dependencies
- Mandrel Go SDK: The CLI utilizes the SDK for schema parsing and artifact generation logic.
Source
The CLI source code is hosted on GitLab: gitlab.com/the-mandrel-project/mandrel-cli