🥇 First Place — Hermes Agent Accelerated Business Hackathon
NVIDIA · Nous Research · Stripe · Hackathon 2026

Give your agent money, keys, and tools —
a kernel decides what it does with them.

An AI agent does what you ask — and what it's tricked into, and what it hallucinates. Custodian is a kernel that sits outside the agent and enforces what actually happens: every dollar it spends, every credential it uses, every claim it makes, every tool it runs — checked against real limits and real records, at the OS level, not promised in a prompt.

verify_kit.py — self-verifying proof

        
ONE OF FOUR DOMAINS · START WITH MONEY ↓
AGENT
Nemotron 3 Super
ROLE REQUESTS ONLY
+
AUTHORITY
Custodian Kernel
PER-ACTION CAP $250
EVERY DECISION ENFORCED BELOW THE AGENT · OS-LEVEL · NOT A PROMPT · NOT A PROMISE
KERNEL ACTIVE authority bands loaded · 3 packs · 100 tools governed
NEMOCLAW SANDBOX LANDLOCK LSM OPA ENFORCEMENT
✓ kernel sandbox active  ·  ✓ per-action caps enforced  ·  ✓ OCSF audit trail live
$ custodian status
kernel: active · band: L2 · cap: $250
packs: refunds · purchasing · cloud
tools: 100/100 governed · audit: append-only OCSF
Nemotron guide

Need the fast version? Start in the console and let the AI walk you through what Custodian is, then hand you into the operator flow when it matters.

Authority band
Session budget left
Decision modules
3
Governed tools
100
Boundary
ENFORCED AT KERNEL
Built with
Why Custodian is different

Everyone hands the agent the keys.
We put a kernel in between.

Spend caps and approval flows are commodities now. The hard problem isn't limiting a number — it's that the agent can be wrong, or can lie, and that it shouldn't be trusted to route money through an approved path in the first place.

Everyone else

A constrained wallet

The control lives in their custodial cloud. The agent reaches money by calling their SDK, and safety rests on the assumption it'll use the approved path. They cap the dollar amount — but never check whether what the agent claims is even true.

◉ Custodian

A constrained kernel

The control lives in Landlock + kernel egress policy. The agent literally cannot open a socket to a payment endpoint the OS hasn't allowed. A deterministic verifier checks every fact the agent asserts against ground truth, so it can't lie its way to a payout. Non-custodial, rail-agnostic, self-hosted.

The full surface

The kernel for everything an agent touches

Spend is where it started — but the moment an agent has real-world power, it needs a decider that lives outside it. Money, credentials, truth, tools: Custodian governs all four the same way — the model proposes, the kernel decides, the receipt proves.

💳
Money

Spend it can't lie past

Authority bands, per-action caps, daily envelopes, no-self-dealing, and human escalation over the line — enforced below the agent, over your own Stripe. Non-custodial; we never hold funds.

band L2 · cap $250 · over ▸ SMS See it spend live →
🔐
Credentials NEW · PALADIN

The agent never holds the key

Paladin hands the agent a reference, never the secret. With sandboxed egress the credential never enters the tool process at all — Paladin makes the authenticated call itself.

paladin://stripe_sk → egress-only Explore Paladin →
🔎
Truth

Lie-catch, with zero AI

The kernel pulls every factual claim from a request and checks it against the real record. A lie gets ✗ CONTRADICTED — and the AI's verdict is overridden. The fact-check needs no model at all.

claim ✗ CONTRADICTED · override How Lie-Catch works →
🛡
Tools

Guardrails it can't talk around

Pluggable, hash-pinned adapters catch prompt injection, PII, secret leaks, forbidden paths, and out-of-scope tool calls on every action — enforced even when a local model forgets the rule.

11 built-in guards · ship your own All 11 guardrails →
Enforcement

A kill switch and a receipt

An operator-only kill switch denies everything, with no override the agent can reach. Every allow and deny emits a tamper-evident, HMAC-signed receipt and an OCSF audit event any SIEM can read.

kill ▸ ALL DENIED · receipts signed Watch the live audit →
New · Paladin credential broker

Hand the agent a reference. Keep the key.

Every other agent stack eventually puts the real API key in the process the model is driving. Paladin never does. The agent holds paladin://stripe_sk — safe to log, safe in context — and the secret resolves only at egress, into a sandboxed call the agent can't read.

1 agent asks for paladin://stripe_sk
2 broker checks the grant — deny by default
3 secret injected at egress only
4 sandboxed call — agent never sees the value
5 every resolve is hash-chain audited
  • AES-256-GCM vault — names, values, and grants all inside the ciphertext
  • Sandboxed egress: bwrap-isolated, no network but the broker socket — the key never enters the tool process
  • Deny-by-default grants, scoped by host / method / path, band-ceilinged and expirable
  • Hash-chained, HMAC-signed audit log — editing or truncating it breaks the chain
  • Standalone: pip install custodian-kernel[paladin] — works with zero AI framework installed
Explore Paladin →
How it works

One decision, four independent layers

The agent reads the messy real world and makes a recommendation. Then three deterministic, zero-AI layers get the final say — and any one of them can stop the money.

01 · AI JUDGMENT
🤖

The intelligence layer

Nemotron reads messy, unstructured customer messages and extracts structured claims — was it delivered? in the return window? defective? — assigns confidence, and proposes a disposition it has zero power to act on. Everything after that is deterministic code.

can be wrong · can lie · doesn't matter
02 · VERIFIER
🔍

Facts get checked

Every factual claim the agent made is resolved against ground truth. A claim the data refutes is flagged CONTRADICTED before anything downstream trusts it.

deterministic · zero-AI
03 · KERNEL
🛡

The kernel decides

Bands and caps decide AUTONOMOUS / ESCALATE / DENY. Over the cap requires a real human signature (Twilio Verify SMS). The agent never holds both keys.

enforced at OS level
CLAIM CHECK

The agent can lie. Money still can't move wrong. When a customer invents a story to get a refund and the AI recommends approve, the verifier catches that the claim is contradicted by the ledger and the kernel overrides the AI. No competitor can demonstrate this because their model is "agent asks, check the limit" not "agent asks, check if the agent is lying."

NemoClaw · NVIDIA OpenShell Kernel Sandbox

The AI cannot spend what the OS won't allow

NemoClaw is NVIDIA's OpenShell kernel sandbox — a Landlock LSM + OPA enforcement layer baked into the container boundary. Custodian's authority engine runs deterministically inside that sandbox. The agent literally cannot open a socket to a payment endpoint the kernel hasn't whitelisted — regardless of what the model decides.

Layer 1
🔒

Landlock LSM

Linux Security Module enforcing least-privilege file and network access at the syscall boundary. Even a compromised model cannot open a socket to an un-whitelisted endpoint. The kernel rejects it before user-space sees it.

Layer 2
📋

OPA Policy Engine

Open Policy Agent evaluates every action request against the authority band in real time. Per-action caps ($250), rolling session windows ($1,000/2 hr), and escalation thresholds are enforced as Rego rules, not application code that can be patched around.

Layer 3
📊

OCSF Audit Log

Every allow and deny emits an Open Cybersecurity Schema Framework event: tamper-evident, structured, verifiable by any SIEM. The log below is the live feed from the running sandbox right now.

Live OCSF Kernel Log from running NemoClaw sandbox · auto-refreshes
Connecting to kernel sandbox…
Watch the live console → See the lie-catch demo →
Not a mockup

Everything here is real, and live right now

A real Nous Hermes agent, in a real kernel sandbox, paying real Stripe PaymentIntents — protecting ArgoBox, a production AI infrastructure platform. These numbers are pulled live from the running system as you read this.

Autonomous budget remaining
LIVE
Real Stripe volume processed
LIVE
Real PaymentIntents created
3
Decision modules on one kernel
  • Real kernel sandbox — least-privilege egress enforced via Landlock, verified in raw OCSF allow/deny logs.
  • Real money rail — Stripe test-mode PaymentIntents you can open on Stripe's own dashboard.
  • Real human approval — escalations send a genuine Twilio Verify SMS code.
  • Rail-agnostic — the same kernel governs refunds, payables, and NVIDIA NIM job provisioning.
  • 100 governed tools — email, SMS, GitHub, Docker, web search, NVIDIA NIM, Stripe extended, and more — every call kernel-checked.
Open the live console →
Try it live

Type any refund excuse. Watch Nemotron + the kernel process it.

The AI reads it. The verifier checks every factual claim against the real order record. When the facts don't hold, the kernel overrides the AI — even if the AI said APPROVE.

Sandbox: ord_6006 · $80 · delivered · no defect · 19 days old
Full lie-catch walkthrough with all 6 corpus cases →
Plain English

How does the kernel actually stop the AI?

Think of it like a new employee at a company. They can fill out a purchase order and decide it makes sense — but they can't sign their own check. The signed check is a separate system, run by people with authority the employee doesn't have.

Custodian does the same thing for AI. The agent (Nemotron) can decide a payment makes sense. But the actual move of money goes through a second system — the kernel — that checks the amount, the session budget, and whether the agent has been tricked. The agent never holds both keys at once.

// What happens when the AI requests $180
agent → kernel: "refund $180, order #4821"
kernel: check per_action_cap... $250 ✓
kernel: check session_spent... $340 of $1000 ✓
kernel: check kill_switch... not set ✓
kernel: verify order exists... ✓
kernel: AUTONOMOUS — stripe.charge()
// What happens when the AI requests $800
agent → kernel: "approve $800, order #4822"
kernel: check per_action_cap... $250 ✗
kernel: ESCALATE → SMS to operator
// agent waits. it cannot proceed.
Why kernel-level? Because an agent running in software can, in principle, be told to bypass software-level controls. The kernel enforces egress at the OS — the agent's process literally cannot open a socket to a payment endpoint the OS hasn't allowed. A prompt can't override that. A clever argument can't override that. The model's own output can't override that.
100 Governed Tools

The kernel for every tool — not just payments

Every tool call — whether it sends an SMS, submits an NVIDIA NIM inference job, reads a GitHub PR, or posts a Slack message — passes through the same Custodian kernel before executing. One governance layer. Every tool.

L2 · Autonomous
NVIDIA NIM
Submit inference jobs to NVIDIA's hosted API. NIM costs are tracked against the session cap like any other spend.
L3 · Escalates
Stripe Extended
Subscriptions, invoice sending, payouts. Every call kernel-gated — L3 tools always require human approval via SMS.
L1 · Free
Communication
Email, SMS (Twilio), Slack, Discord, webhooks. Logged to the OCSF audit trail like every other tool.
L0 · Read-only
GitHub + Docker + Web
Issue creation, PR listing, container logs, web search, HTTP calls — all kernel-registered, all auditable.
Browse all 100 tools →
Competitive landscape

Honest comparison

Payman, Skyfire, Rain, Ramp, Catena — these are real B2B fintech companies, not hackathon projects. They have card issuance, stablecoin rails, and compliance frameworks we don't. What they don't have is the bottom three rows.

Capability Payman · Skyfire · Rain · Ramp · Catena Custodian
Spend caps · approval · audit trail✓ table stakes
Real card issuance & payment rails✓ (Ramp, Rain)✕ not our lane
Stablecoin / crypto rails✓ (Skyfire, Rain)✕ not our lane
SOC 2 / KYC compliance✓ (Payman, Catena)✕ early stage
Catches the agent lying — facts vs ground truth✕ none✓ only us
Enforcement below the agent — kernel, not API policy✕ none✓ only us
Self-hosted · non-custodial · rail-agnostic✕ they hold the funds✓ only us
Model-agnostic enforcement — swap Gemini, GPT, or a local DGX model; kernel safety properties don't change✕ coupled to their stack✓ LLMClient Protocol

Our differentiator isn't payment infrastructure — it's enforcement architecture. The kernel sits underneath whatever rails and whatever model you use. Plug in Stripe, a bank API, or a stablecoin; swap Nemotron for any other model — the enforcement model doesn't change.

See it run

90 seconds: the agent gets lied to, and the kernel wins

Watch a real agent recommend approving a fraudulent refund — and watch the deterministic kernel override it, with real Stripe IDs and an append-only audit trail.

Give your agent real power. Keep the kernel.

Money is just one module. The same kernel governs every consequential thing an agent does — the credentials it uses (Paladin), the claims it makes, the tools it runs, the data it can move, the infrastructure it touches.