run_commands
Execute policy-approved diagnostic commands on a Prisma SD-WAN ION over SSH, rejecting any disallowed command before connecting.
Instructions
Run a batch of policy-approved commands on one Prisma SD-WAN ION over SSH.
Approved: the display-only dump and inspect families, plus the exact
active-diagnostic forms ping, tcpping, and dig -- see the
prisma-cli://policy resource. The diagnostics send real packets from
the device; everything else is denied fail-closed, with no deny list --
an unmatched command is refused by construction. One denied command
rejects the whole batch before any connection is opened.
Call order is fixed and load-bearing: policy validation, then credential availability, then device address resolution, then a bounded TCP reachability probe, then the SSH session itself. A policy denial never reaches address resolution; a missing credential never triggers a resolution call.
Args:
commands: One or more ION CLI commands. See the prisma-cli://policy
resource for the exact approved forms. The whole batch is
rejected if any single command fails the policy.
element: Element name or controller ID to target, resolved to an SSH
address via the same resolver every other tool uses. Required
unless host is given.
host: Explicit device address. Always wins: when it is given, no
resolution happens and the address is used exactly as supplied.
Use it whenever you already know the address, or for a management
network the controller API cannot see. Supplying element
alongside it is allowed -- the element is then only a label on
the response, and nothing is resolved or cross-checked.
site: Optional site name/ID to disambiguate element, as in every
other semantic tool. Ignored when host is given.
Credentials, SSH port and known_hosts path come from the server's
configuration only -- ION_USERNAME, ION_PASSWORD (or ION_PRIVATE_KEY),
ION_SSH_PORT, ION_KNOWN_HOSTS. There is deliberately no per-call override:
a tool argument is visible to the model and lands in the conversation
transcript, which is normally logged. With nothing configured the call
fails closed with configuration_error before any resolution, probe or
connection. Host-key checking is always strict -- an unknown or mismatched
key fails before credentials are sent, as host_key_unverified.
Each command's output is capped independently (the server's configured
cap divided across the batch, floored), and every result declares
whether it was truncated. A device rejection is that command's own
status "error"; sibling commands keep their own status and output.
Completion is decided by the device's prompt reappearing, never by
elapsed time -- a slow ping is read to completion, not cut short.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Explicit device address. Always wins: when it is given, no resolution happens and the address is used exactly as supplied. Use it whenever you already know the address, or for a management network the controller API cannot see. Supplying `element` alongside it is allowed -- the element is then only a label on the response, and nothing is resolved or cross-checked. | |
| site | No | Optional site name/ID to disambiguate `element`, as in every other semantic tool. Ignored when `host` is given. | |
| element | No | Element name or controller ID to target, resolved to an SSH address via the same resolver every other tool uses. Required unless `host` is given. | |
| commands | Yes | One or more ION CLI commands. See the `prisma-cli://policy` resource for the exact approved forms. The whole batch is rejected if any single command fails the policy. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |