delego

Website: delegohq.com · Docs: delegohq.com/docs · Spec: Delego-Dev/specification

Intent-bound action authorization for AI agents. It sits between an agent and whatever credential broker holds the user's secrets, and it answers the one question brokers don't: is this specific action the thing the human actually asked for?

   agent  ──propose──▶  delego  ──if allowed──▶  credential broker  ──▶  service
   (LLM)               (policy +                (Agent Vault /         (bank,
                        approval +               OneCLI /               SaaS,
                        audit)                   Browser Use…)          API)
                           │
                           └── needs_approval ──▶  human (CLI)

📜 Protocol: delego implements protocol 0.3 of the open delego wire specification — canonicalization, the policy schema, intent/fingerprint binding including the §4.2 query-fold, and the signed audit chain. The authorization token (spec §9) is an optional profile, not yet implemented.

Why this exists

The "agent gets its own scoped credential, and never holds the user's secret directly" pattern is now a crowded, converging space — Infisical's Agent Vault, OneCLI, Browser Use, Nango, and others all do credential brokering.

The harder problem sits one level up — the confused deputy: the agent holds a valid credential, a prompt injection redirects it, the scope covers the action, so the broker happily injects the secret and the action goes through. The credential is the wrong place to catch this — it's valid. OAuth tokens carry no commitment to the original instruction.

Authorising the action (not just the credential) is an active area — see deterministic policy engines (OPA/Cedar, Permit), human-in-the-loop approval (HumanLayer), MCP gateways/firewalls, and the "pre-action authorization" line of research. delego is a small, deterministic, local, Apache-2.0 reference for it: no LLM in the decision path, no credential custody, approvals bound to the exact action fingerprint, and a signed, hash-chained audit trail — riding the existing broker layer rather than competing with it.

What it is / isn't

• Is a decision-and-audit layer. Deterministic policy, human approval for sensitive actions, signed append-only audit ledger.
• Isn't a credential vault or a proxy. It delegates execution to a broker through a thin BrokerAdapter interface — you ride the existing layer instead of rebuilding it.
• Authorisation is pure Python, no LLM in the loop. A model can advise upstream; the decision that gates a credential is made outside the stochastic loop, so an injection can't talk its way past it.

Key properties

1. Intent binding — every action carries a hash of the original human instruction, recorded in the audit ledger and re-checked at resolve time, so an approval cannot be re-pointed at a different claimed instruction.
2. Action-bound, single-use approval — a human "yes" is bound to one exact action fingerprint. An agent that gets approval for action A cannot reuse it to run action B (the confused-deputy guard), and cannot replay the same approval to run action A twice — an approval releases its action exactly once.
3. Tamper-evident audit — receipts form an Ed25519-signed hash chain. Editing, reordering, removing a receipt, or dropping a field breaks verification, which reports t

... View full README on GitHub