Using the DALP CLI with AI agents

OverviewCopy Anchor Link

An AI agent can drive the DALP CLI the same way a person does, from a shell. Two purpose-built integration modes also exist: an MCP server that exposes dalp commands as callable tools, and a skill file an agent reads to learn the command tree without shelling out first. Both modes read from the same generated command tree covered in CLI commands.

The agent does not get a separate authority model. Every command it prepares uses the authenticated account, the active organisation, the assigned roles, and the same API validation that applies when you run a command yourself. The first half of this page covers the integration mechanics; the second half covers how an operator scopes that session and which operations need a human sign-off before they run.

dalp login, dalp logout, dalp config, and the two agent-integration commands below do not require you to already be logged in; every other command does.

Shell modeCopy Anchor Link

An agent that already has a shell tool can call dalp directly, exactly as a person would from a terminal.

Set --format json, or jsonl for a streaming command. This gives the agent structured output instead of the human-oriented toon default.

dalp get tokens --format json

Registering an MCP serverCopy Anchor Link

Run the CLI's own mcp command to register itself as an MCP server with a compatible agent:

dalp mcp add

This registers every generated command as a callable MCP tool. Use dalp mcp doctor to verify the registration is healthy after setup or after upgrading the CLI.

Registering a skillCopy Anchor Link

Run skills add to install a skill file that teaches an agent the command tree directly, without a round trip through --help:

dalp skills add

dalp skills list shows which supported agents already have the skill installed. Both mcp add and skills add finish by suggesting example prompts scoped to what the CLI actually does, for example asking the agent to log in, list tokens, switch the active organization, or check whoami.

Safe patterns for agent-driven commandsCopy Anchor Link

• Run dalp whoami and dalp org current before letting an agent run a mutation, so both you and the agent confirm which account and organization a command will act against.
• A mutating command (create, patch, replace, delete) asks the platform to hold the response until the write settles, and --no-wait asks it to answer at once. Neither makes the CLI poll: a write that outlives the wait returns a handle, and the command says Request accepted; the transaction is still settling. An agent must inspect the returned handle before reporting completion. Follow statusUrl; resubmitting with a new idempotency key can create a second instruction.
• Prefer --format json or --schema over parsing toon or human help text. --schema returns a command's argument and output shape as JSON Schema, which an agent can validate against before it runs anything.
• Treat any command under delete, patch, or replace as requiring explicit confirmation in your agent's own policy; the CLI itself does not prompt for confirmation before a mutating call.

Operating an organisation with an assistantCopy Anchor Link

The rest of this page is for an operator deciding whether, and how, to let an assistant touch a live organisation rather than a build or test pipeline. The assistant is not a separate DALP role: it inherits the authenticated account, active organisation, visible data, and assigned roles of the session you give it, so the same permission checks and API validation apply to every command it runs. If those credentials allow minting, pausing, inviting users, or changing compliance provider state, the assistant can prepare the same operations. Give the assistant the narrowest session that can do the job, and use a separate account with only the roles the task needs when your operating model calls for tighter supervision. Install and configure the DALP CLI covers authentication and pinning the active organisation before a session starts.

Privileged operations need a human sign-offCopy Anchor Link

Use an assistant for inspection and for preparing commands. Keep execution of a privileged command under operator review, with the operator accountable for each run. An assistant must not run a command that changes token state, identity or compliance records, or platform access without a human operator approving it first:

• creating a token, or minting, burning, pausing, or unpausing one.
• changing platform access roles.
• submitting or approving an identity or KYC record.
• changing a compliance provider's state, secret, or webhook configuration.
• retrying a failed webhook delivery, or re-running a mutation after an unclear result, since a blind retry against a consumer that already processed the first attempt can duplicate its effect.

Apply these rules on every run:

• Have the assistant read current state before it proposes a mutation.
• Confirm the exact command, including the target token, address, amount, and organisation, before approving it.
• Keep high-risk operations under the same approval process you already use for Console or CLI work.
• Use roles to limit what the authenticated account can do. Prompt wording is not a permission control.
• Keep credentials in the CLI's local credential store. Do not paste an API key, session token, or participant data into the assistant conversation.
• Treat assistant output as a draft until you check it against the CLI's own JSON output.

Safe operating patternCopy Anchor Link

1. Inspect current state with a read-only command.
2. Ask the assistant to propose one exact mutation command.
3. Review the command: the organisation, the target resource, and the expected effect.
4. Run the approved command yourself, or approve the assistant running it.
5. Inspect the target state again when the result is unclear.
6. Keep the CLI's own response as your evidence, not the assistant's summary of it.
7. If the inspected state still does not match what you approved, stop. Escalate through your incident process before another mutation. Retain the exact command and the CLI's before-and-after output as evidence.

Do not let an assistant retry a failed mutation on its own judgment. If a command times out or returns an unclear error, inspect the target state again before retrying.

What the assistant should returnCopy Anchor Link

Before approving a privileged command, ask the assistant for a short run note. Require these facts:

Keep secrets, API keys, and recovery material out of the run note. Leaving them out keeps sensitive data from landing in conversation history or logs.

What stays outside the assistantCopy Anchor Link

A prompt or an instruction file is not a security control. The platform account, wallet custody, and your human approval process decide what is allowed. Keep each of the following entirely outside the assistant:

• DALP roles and organisation membership.
• wallet custody and transaction signing policy.
• approval policy for privileged operations.
• API keys, session credentials, and recovery material.
• incident escalation and final operational sign-off.

A command like mint, burn, pause, or unpause is a platform-side state change: the assistant can prepare and, with your approval, submit it through the API. Whether that submitted operation is actually signed, and by what key, is a separate custody decision the platform and your signing backend make; the API resolves signing through the configured custody path. Keep private signing keys outside the assistant environment.

No platform switch controls thisCopy Anchor Link

No configuration field, in the platform's own settings schema, enables, disables, or scopes AI-assistant access. Nothing under a deployment's configuration names an "AI assistant" or "AI agent" toggle. An assistant is an ordinary CLI session, indistinguishable from a human running the same commands from the same workstation, and the platform applies the same credential and permission checks to both. Your team owns the session limits and approval process described here. You enforce it through role scoping and your own approval process, not a switch the platform flips for you. If you need to restrict what an assistant-driven session can do, restrict it the same way you would restrict any other CLI session: through the roles assigned to the account it authenticates as.

Next stepsCopy Anchor Link

• Install and configure the DALP CLI covers authentication, configuration precedence, and credential storage that apply the same way whether a person or an agent runs the command.
• Read security and compliance posture for the control layers a privileged command still has to pass.