Skip to content

Heimdall Skills

This directory contains OpenClaw skill definitions for Heimdall integrations.

Available Skills

heimdall-ai-agent

Download the raw SKILL.md file — served unmodified (ready to paste into your OpenClaw agent config).

Skill for AI agents to obtain user-delegated, time-boxed access to data sources through Heimdall's portal session model. A human holds a running session in the Heimdall UI and, from its Credentials cell, issues an AI token that delegates the roles they are allowed to delegate — only roles they currently hold via live group membership on that data source and that are auto-approved per role configuration (break-glass and approver-gated roles are not delegable) — for a fixed window. The agent presents the token as a Bearer credential, requests scoped sub-sessions, polls them once STARTED, and receives the session's temporary database credentials on the same terms a human would see in the UI.

The skill covers: - POST /api/ai/tokens/sessions — request a delegated sub-session (agent side) - GET /api/ai/tokens/sessions/{id} — poll for state + temporary credentials once running (agent side) - GET /api/ai/data-sources and GET /api/ai/user-roles?dataSourceName= — discovery of delegable sources/roles (portal-authenticated, agent side) - Brute-force guard: Bearer attempts are rate-limited per client IP (token bucket, ~30 sustained) and return 429 "Too many AI token attempts; back off." before token resolution; a separate 429 caps sub-sessions at 3 active / 5 total per token - Audit: every delegated request's justification is stored prefixed [AI agent] (or [AI agent] (no justification supplied) when omitted) so delegation entries are unambiguous in the trail - Sub-sessions run through the standard portal session pipeline — same approval, lifetime and audit behavior; roles delegated via the token are pre-approved by delegation, approver email is skipped, all requests are flagged aiInitiated in the audit trail with the source token id. - Temporary credentials auto-cleaned on expiry/termination of the sub-session. - Token lifecycle (issue / list / revoke) belongs to the human user in the sessions UI or via /api/ai/tokens under portal auth; revocation blocks any new sub-sessions from that token immediately.

Agent side: how a delegated request flows

  1. The agent already holds an AI token for the data work (see "Where the agent gets the token" below); it is a secret.
  2. GET /api/ai/tokens/sessions/{id} or issue path tells it which roles and window are available; sub-session durations are clamped to the token's remaining lifetime at creation time — never assume you can request more than what the token still has left.
  3. Each successful poll of a STARTED sub-session carries sessionUsername / sessionPassword for that session's ephemeral database user, scoped to exactly the role set the user delegated and no wider.

This is a least-privilege delegation skill: an agent can only do what its issuing user chose to delegate, only while the token is unexpired/unrevoked, and only up to a hard per-token cap (3 active / 5 total sub-sessions, see "Limits" in the skill file). Nothing here escalates, proxies or impersonates — the underlying human's identity stays visible end-to-end.