Hawkeye's session recording with cost tracking is solid. One thing we found building nornr.com?ref=m_368865: capturing costs after the fact is necessary but not sufficient. Agents also need a pre-execution policy check, a mandate they request before spending. The receipt from that decision then feeds into exactly the kind of audit trail you're building. Could see these composing well together.
Great research. The 93% unscoped key finding matches what we see in practice. We built nornr.com specifically for the spend side of this: agents request a mandate before any financial action, policy scopes what's allowed (amount, vendor, frequency), every decision gets a signed receipt for audit. Works with existing payment rails. The delegation and revocation gaps you identified are first class concerns in our model. Would be interesting to see how your framework scores projects that adopt a mandate based approach.
This is exactly the problem we built nornr.com to solve. Instead of giving the agent a card directly, the agent requests a mandate before each purchase. Your policy layer decides approved, queued, or blocked based on amount, vendor, frequency, whatever rules you set. Every decision gets a signed receipt for audit. Works with Stripe, virtual cards, PayPal. No blockchain. Free tier if you want to try it against your MCP server.
We hit this exact problem and built NORNR (nornr.com) around it. Instead of trying to forecast costs upfront, we enforce them at runtime. Every agent action that involves spend has to request a mandate first. Policy decides approved, queued, or blocked based on budget, rate, context, whatever you define. Every decision gets a signed receipt so you have a full audit trail. It doesn't replace your cost estimates but it puts a hard ceiling on what agents can actually spend. Free tier if you want to try it.
We are not trying to persuade teams that agents should suddenly be given money for the first time. We are reacting to the fact that many agent workflows are already close to real economic actions: buying API usage, triggering vendor services, provisioning paid infrastructure, or moving toward delegated purchasing flows.
Our view is that if those workflows are happening anyway, the dangerous setup is not “agent with constraints”. The dangerous setup is “agent with no mandate, no approval thresholds, and no evidence trail”.
So the goal of NORNR is not to encourage reckless autonomy. It is to put policy, approvals, and auditability between intent and settlement.
In other words: if an agent is going to touch spend, we think the default should be more governance, not less.
We built NORNR because once agents start buying APIs, vendors, or services, the hard part is no longer the payment rail. It is deciding whether that spend should happen at all.
NORNR sits between intent and settlement. Policy decides whether something is approved, queued, or rejected. Human approvals kick in when thresholds or counterparties require it. Receipts, manifests, and evidence stay attached to the decision trail.
What is live today:
Quickstart: https://nornr.com/quickstart
Control room: https://nornr.com/app
Python and TypeScript SDKs
Design partner application flow
Live on-chain settlement proof on the launch page (Base Sepolia)
This is the exact problem we're solving at nornr.com. Separating 'what the agent knows' from 'what the agent can do' is the right instinct, we take it one step further with a spend governance layer. Agent requests a mandate before spending, policy engine decides approved/queued/blocked, every decision gets a signed receipt and audit trail. Works with existing payment rails, no blockchain. Free tier if you want to try it. Happy to talk architecture if you're hitting specific edge cases.
Your observation about the real failure mode being 'agent makes 10,000 correct $0.02 decisions that collectively don't make sense' is spot on. That's why per-call rate limits don't work, you need policy that evaluates context and aggregate state. We built nornr.com for exactly this: agents request a mandate before spending, policy evaluates (budget, intent, history), returns approved/queued/blocked with a signed receipt. Works with existing payment rails. Happy to compare notes on what you've learned running this in production.
Good framing on where governance should live. Intercepting actions outside the prompt and outside the framework is the right call, the model and the orchestrator are both untrusted surfaces. We took the same approach for spend specifically at nornr.com: agent requests a mandate before committing money, policy decides approve/queue/block at the infrastructure layer, every decision gets a signed receipt. Curious whether DashClaw distinguishes between 'read' actions and 'actions that cost money' — that's where we found the policy logic gets interesting.
reply