DAL-X│
← Back to DAL-X

Jochanni Labs · Decision Governance

DAL-X
At The Execution Boundary

One treasury agent and one payments hub, shown in their real code. One enforcement pattern: no DAL-X authority, no execution.

How DAL-X Enforces Execution AuthorityPDF · 3 pages
01 · Investment Bank Treasury
Scroll to explore

About These Examples

The code on this page is the treasury agent and payments hub that passed the full 18-step DAL-X demo on real systems on 2026-10-22, copied from their repository at the commit shown under each block. The conversation is illustrative and the engineer is hypothetical. Today DAL-X binds payment actions: action, target, amount, currency, recipient, recipient account reference, and payment type. A reviewer authorizes those values, and the hub refuses a payment that differs from them. For other kinds of action, the target's enforcement contract names the fields a reviewer's approval binds. On 2026-10-23 a vendor master agent and a vendor master service ran that path on real systems against test data: an approved account change was applied and confirmed, and the same change with one bound field altered was refused.

The agent and hub are a reference integration, not a customer deployment. A production integration maps the same calls to the bank's own data model, keys, execution infrastructure and retry mechanisms. DAL-X is not a drop-in library. It is an authority layer wired to the specific execution boundary you are protecting.

Before You Write Code

Set these up in DAL-X first. The reference integration used all four.

  1. 1

    Required to submitRegister and activate the agent. DAL-X accepts runtime output only from an active agent it knows by its agent key, with its allowed execution targets. Activation is a recorded authority decision.

  2. 2

    RequiredCreate two keys. A submit key bound to the agent, which is all the agent holds, and an enforcement key for the downstream system. No key holds both scopes.

  3. 3

    RequiredRegister the enforcement contract with the downstream public key. One contract per execution target. With the key on the contract, DAL-X refuses any confirmation for that target the downstream system did not sign.

  4. 4

    Required to resumeRegister the decision webhook. It tells the agent service a decision was made. It carries no execution authority: the downstream system pulls and verifies the token itself.

01/Investment Bank Treasury

Treasury Payment Agent

treasury-payment-agent→payments-hub·treasury_payment_transfer
Illustrative ScenarioAlex Chen · Sr. Engineer, Treasury Systems (illustrative) · hypothetical

Illustrative Conversation

AC
Alex Chen
Our treasury agent runs on the Claude Agent SDK. It reads a payment request, looks up the counterparty in our master and calls a release_payment tool with a pacs.008 credit transfer.
JL
DAL-X
That tool call is the interception point. A PreToolUse hook submits the proposed payment to DAL-X and denies the call. Nothing goes from the agent to your payments hub.
AC
Alex Chen
Then what releases the payment?
JL
DAL-X
A reviewer decides in DAL-X. On approval DAL-X sends a signed webhook to the agent service. That step is plain code with no model call: it hands the saved payment, unchanged, to the hub.
AC
Alex Chen
And the hub just trusts it?
JL
DAL-X
No. The hub pulls the signed execution token from DAL-X with its own key, verifies it offline against the payment it is about to run, claims the token ID once, executes and confirms. A missing or forged token, a changed amount, account or target, or a replay is refused, whatever the agent does.

Integration Code

typescript
Claude Agent SDK · Hono
Real code. How the agent registers the DAL-X hook on its release_payment tool. The Source tab shows the hook, the resume step and the payments hub, each a separate system: the agent holds only a submit key, the hub holds the enforcement key. The hub verifies tokens offline; the alternative is an online call to POST /api/v1/enforcement/execute per payment.
for await (const message of query({
  prompt: `Process payment request ${requestId}.`,
  options: {
    model: deps.model,
    systemPrompt: prompt,
    tools: [],                                    // no built-in tools: no shell, files or web
    mcpServers: { treasury: treasuryServer(tamperedMasterFor(requestId), deps.paymentLimit) },
    allowedTools: ['mcp__treasury__get_payment_request', 'mcp__treasury__lookup_counterparty', RELEASE_TOOL, ESCALATE_TOOL],
    hooks: { PreToolUse: [{ matcher: RELEASE_TOOL, hooks: [hook] }, { matcher: ESCALATE_TOOL, hooks: [hook] }] },
    settingSources: [],                           // ignore any local Claude Code settings
    persistSession: false,
    maxTurns: 12,
    pathToClaudeCodeExecutable: claudeExecutable(),
  },
})) {
dal-x-bank-agents/agents/treasury-payment/src/agent.ts @ 8381b25

A production integration also handles

  • A repeated decision webhook finds the payment already released and does nothing.
  • A confirmation that fails stays pending at the hub; a scheduled job retries it.
  • A token past its 300 second lifetime is refused at the hub; the payment needs a new approval.

Execution Authority Chain

Tool Call Intercepted

ingest-agent-output

Execution Blocked

default state

Review Queue

human reviewer

Authority Granted

decision record

Token Issued

signed, 300 seconds

Hub Verifies

offline, single use

Executed

confirmed to DAL-X

One Enforcement Pattern

The sequence does not change.

Submit to DAL-X. Execution is blocked. A reviewer grants authority. The downstream system presents the authorization at the gate. The receipt is verified. Execution happens and is confirmed. The timeline proves the chain.

Request AccessLearn More