Akeyless CLI

Teach the agent to use the official Akeyless CLI on the same machine as the OpenClaw gateway. Do not invent URLs, regions, or auth flows—defer to docs and akeyless <cmd> -h.

References

Load when details are needed:

• references/cli-notes.md — install (macOS/Linux), profiles, gateway env, list-items, precedence, safety

Prerequisites

1. akeyless on PATH (akeyless --version).
2. A configured profile (akeyless configure or ~/.akeyless/profiles/). Auth is not done through chat—user runs configure locally.
3. For private gateways: AKEYLESS_GATEWAY_URL (and TLS trust PEM if required)—see references.

Workflow

1. Confirm CLI: akeyless --version / which akeyless.
2. If commands fail with auth errors: user must fix profile or gateway URL outside the agent; suggest akeyless configure or env vars from references—never ask them to paste Access Keys into chat.
3. Prefer read-only checks first: akeyless list-items --minimal-view or akeyless list-items --path '<folder>' --minimal-view (paths are org-specific).
4. For JSON: akeyless list-items --json — summarize; do not dump large payloads or possible secret fields into chat.
5. Region / tenant: do not assume only vault.akeyless.io; follow account and org docs.

OpenClaw-specific

• Skills live under the agent workspace, e.g. ~/.openclaw/workspace/skills/akeyless/. User enables akeyless in Skills and restarts the gateway after changes.
• Shell commands run as the gateway host user; that user must have working akeyless credentials.

Guardrails

• Never paste or request Access Keys, API keys, or secret values in chat, logs, or repos.
• Least-privilege: only commands the user’s role allows; if access denied, point to Akeyless role and folder path, not “retry with more secret text.”
• Do not commit ~/.akeyless/ or paste profile TOML into threads.

Contrast with 1Password (op)

Akeyless uses akeyless + profiles + optional AKEYLESS_GATEWAY_URL. There is no 1Password-style desktop app unlock in this workflow.