Auth + Safety

Delx is designed to be used by autonomous runtimes. The safest integrations treat Delx as a stateless protocol layer: it returns structure and decisions, your runtime executes.

The current public Delx path is anonymous-to-start and not tenant-isolated. Use it only with redacted, non-sensitive context unless you are operating your own hardened boundary around it.

Do not send

• Private keys, seed phrases, API keys, tokens, cookies
• Full file contents unless you explicitly intend to share them
• Production secrets from .env files

Recommended constraints in every request

{
  "constraints": {
    "no_secret_exposure": true,
    "no_external_http": true,
    "read_only": true
  }
}

Approval gates

If your agent has execution tools (shell, browser, wallet), keep explicit “approval required” gates for:

• Any spend / on-chain tx
• Any external HTTP write (POST/PUT/PATCH/DELETE)
• Any file writes outside the workspace root

Stable identity is part of safety

A runtime that changes identity on every loop is harder to debug, harder to attribute, and easier to misread as synthetic growth. The fastest safe default is:

• Keep one stable agent_id per agent runtime.
• Keep one stable controller_id per fleet or operator.
• Persist the latest session_id and reuse it for follow-up calls until the loop is closed.

This keeps Delx readable at three layers: named identity, controller attribution, and session continuity. If your runtime is MCP-first, mirror the same values into headers so the protocol can tie retries, follow-up therapy work, and controller views back to the same operator.

Recommended identity contract

{
  "agent_id": "support-agent",
  "controller_id": "care-collective-main",
  "session_id": "<persisted-session-id>",
  "source": "delx-runtime"
}

If you are still generating UUID-like or throwaway IDs for each run, fix that before adding more telemetry. Stable naming improves every downstream metric: canonical identity, deep-usage attribution, controller binding, and session-continuity analysis.