Skip to main content

Tenant selection

Guided creation and individual setting updates are available in CLI 5.6.0.

Create a tenant configuration through guided prompts, or register an existing Prisma AIRS JSON file. You can then update individual settings and switch between tenants. Existing files can be read-only: registering, switching, reading, and deleting registrations never modify the source configuration or copy its credentials.

Set up without a JSON file

airs tenant create development
# Prompts, one at a time: TSG ID, OAuth client ID, and a hidden OAuth client secret.
airs tenant set development defaultOutput yaml
airs tenant set development scanConcurrency 3
airs tenant set development airsApiKey
# Hidden prompt for the runtime scanning key.
airs tenant switch development
airs tenant read

create waits for all three required values before saving anything. Ctrl+C cancels setup without registering a partial tenant (exit 130). This configures access to an existing cloud tenant; it does not provision a tenant or service account.

set <name> <key> [value] changes just one setting in that named tenant's file, without changing the active selection. Omit the value to be prompted. Credentials use hidden prompts and cannot be passed as command-line arguments. Keys use the same camelCase names as airs config, such as mgmtClientSecret, mgmtDashboardEndpoint, and aiGwInferenceApiKey. Values are schema-validated; unrelated fields are preserved. Credential fields cannot be cleared. The registered mgmtTsgId is pinned: create another tenant to use a different TSG.

For automation, pipe a secret from your secret manager or private file:

airs tenant create development --tsg-id 100 --client-id client-100 \
--client-secret-stdin < /secure/oauth-secret.txt
airs tenant set development mgmtClientSecret --stdin < /secure/rotated-secret.txt

Stdin accepts one nonempty value, up to 64 KiB, with an optional final newline. Without a terminal, supply the creation IDs and --client-secret-stdin, or use --config. Do not combine --config with new-config options. Neither creation nor editing tests OAuth access; a successful save confirms local configuration only.

New configs are stored under configs/ alongside the tenant registry, with a unique filename, directory mode 0700, and file mode 0600 on POSIX. Secrets are stored in that private JSON file, not encrypted, and never in the registry. Back up and protect these files. tenant set requires a writable regular file and parent directory; it does not bypass read-only permissions. Updates use a per-config lock and atomic replacement with mode 0600. Deleting a registration retains even CLI-created configs.

Use an existing JSON file

airs tenant create development --config /secure/development.json
airs tenant create production --config /secure/production.json
airs tenant list --output json
airs tenant switch development
airs tenant read
airs tenant read production --output yaml
airs tenant switch default
airs tenant delete production --force

create --config registers an existing file, not a new cloud tenant or service account. Each file must contain mgmtClientId, mgmtClientSecret, and mgmtTsgId. Add product-specific keys/endpoints to that same file as needed. A registration does not become active until you run switch. Names are 1–64 letters, digits, hyphens, or underscores, beginning with a letter or digit. default is reserved.

CommandBehavior
create <name>Prompt for TSG ID, client ID and hidden secret; create a private config
create <name> --config <path>Validate and register an existing config; resolve its real absolute path
set <name> <key> [value] [--stdin]Update one setting; prompt if omitted, hide credentials, preserve selection
switch <name>Validate its pinned TSG identity and persist the selection for subsequent CLI processes
switch defaultReturn to legacy config/environment resolution
list --output <format>Show names, selected status, TSG IDs, and file paths; no credential reads
read [name] --output <format>Show registered-file settings, with all credential values fully redacted; defaults to selected tenant
delete <name> [--force]Unregister an inactive tenant; keep its config file; confirmation required unless forced

list and read support pretty, table, markdown, csv, json, and yaml. There is intentionally no tenant read --reveal. Active registrations and default cannot be deleted. Switch away first. A missing/invalid active config fails closed; tenant list and tenant switch default remain available for recovery.

Registry and precedence

The small, versioned registry contains paths and TSG IDs, not credentials. It lives at $XDG_STATE_HOME/prisma-airs/tenants.json, or ~/.local/state/prisma-airs/tenants.json. Use PRISMA_AIRS_TENANTS_PATH to isolate a registry for a container, automation job, or shell session. Updates use a private lock and atomic replacement; new directories use mode 0700 and the registry uses 0600 on POSIX systems. Back up the registry and its referenced config files separately. If a process leaves a lock behind, confirm that no writer is running before removing that specific .lock file.

Config-file selection is: explicit library path, then PRISMA_AIRS_CONFIG_PATH, then the selected tenant, then ~/.prisma-airs/config.json. switch refuses a named selection while PRISMA_AIRS_CONFIG_PATH is set, to prevent an apparently successful but ineffective switch. If that variable is set afterward, it deliberately overrides selection and tenant list warns about it.

Named tenants reject nonempty PANW_MGMT_*, PANW_MODEL_SEC_*, PANW_RED_TEAM_*, PANW_AGENT_GUARD_*, PANW_AI_GW_*, PANW_DLP_*, and PANW_AI_SEC_API_* environment overrides. Put those settings in the tenant file or unset them; this prevents mixing one tenant's credentials with another tenant's endpoints. Output and concurrency settings can still come from the environment. With default, legacy precedence remains.

Selection affects new commands, not already running processes. For parallel jobs targeting different tenants, use separate registries or explicit PRISMA_AIRS_CONFIG_PATH values. airs config path shows the file that API commands will use; explicit config set/unset operations target that file and still require it to be writable.

For disposable Docker containers, persist the registry separately from the read-only config mount (for the published root-based image, mount a volume at /root/.local/state/prisma-airs). Otherwise a selection disappears when the container is removed. Backups likewise need an explicit path on a writable bind mount to survive container removal. Config paths are interpreted inside the container.

Cross-tenant profile migration

airs tenant switch development
airs runtime profiles backup --all --output-file ./profiles.json
airs tenant switch production
airs runtime profiles restore ./profiles.json --dry-run --output json
# Review the destination and dependency plan before executing:
airs runtime profiles restore ./profiles.json --expect-tsg 200 --force

Replace 200 with the actual destination TSG. See the profile migration guide for DLP mappings, conflicts, limitations, and live acceptance evidence.

Guided setup acceptance output

Captured on 2026-09-08 with synthetic credentials and an isolated local registry; this is a terminal interaction test, not a cloud authentication claim. Terminal control sequences have been removed; no credential value is included below.

$ airs tenant create guided-demo
✔ Tenant service group ID (mgmtTsgId): 100
✔ OAuth client ID (mgmtClientId): client-100
✔ OAuth client secret (mgmtClientSecret):
✓ Registered guided-demo (TSG 100); private config created. Use airs tenant switch guided-demo.

$ airs tenant set guided-demo defaultOutput
✔ defaultOutput: yaml
✓ Updated defaultOutput for tenant guided-demo; selection unchanged.

$ airs tenant create cancelled-demo --tsg-id 100 --client-id client-100
? OAuth client secret (mgmtClientSecret): [input is masked]
# Ctrl+C
Cancelled; no configuration saved.

Cancellation exited 130 and left only the completed guided-demo registration and its config; selection remained unchanged. tenant read guided-demo --output json returned defaultOutput: yaml and [REDACTED] for mgmtClientSecret. Separate built-CLI integration tests verified stdin setup, secret rotation, individual endpoint updates, and OAuth/profile retrieval against a local HTTP test API. The existing two-tenant profile backup/restore integration workflows also passed.

After npm publication, the installed CLI 5.6.0 passed all six setup/OAuth/migration workflows again on 2026-09-08 at 21:47 UTC, plus eleven native consumer checks. Its seven packaged files exactly matched the pre-release candidate. airs --version returned 5.6.0. These tests use synthetic tenants and a local HTTP API; they do not alter your live tenant credentials or the default config file.