Human-in-the-loop approval for AI agents: build it or buy it?

We sell one of these, so treat this page with appropriate suspicion. It is still the honest answer, and the honest answer starts with: most teams should build it themselves, and should not pay us.

Build it. Seriously.

A competent platform engineer builds a working approval gate in about a week:

• Intercept the tool call before it executes.
• Write the pending action to a table.
• Post a Slack message with Approve / Deny buttons.
• Resume the call when the webhook comes back.
• Log who clicked.

This is a good design. It is the right first move, it will handle your first thousand escalations, and if someone tries to sell you a platform before you have built this, they are selling you a solution to a problem you have not yet had.

Build it. Then read the next section and work out whether you are in it.

The single question that decides it

Will anyone, ever, have to prove one of these approvals to a party who does not trust you?

An auditor. A regulator. A customer's security team during a review. Opposing counsel. Your own board after an incident.

If the answer is no — genuinely no — stop here. The Slack button wins. It is cheaper, it is simpler, it has no vendor in the path, and nothing on this site will make your agent safer than a well-placed if statement. We would rather you closed the tab than bought something you don't need.

If the answer is yes, your Slack button has a specific, fatal problem, and it is worth being precise about what it is — because it is not "it doesn't work."

What breaks, exactly

Your approval record is a database row. It is mutable by everyone with write access to that database: your engineers, your CI, your migrations, anyone who compromises any of them — and the person you are trying to hold accountable.

So when the question arrives —

"Prove that Priya, and not a compromised service account, approved this specific $9,000 payment, and that nobody edited the record afterwards."

— the honest answer is "our database says she did." Which is testimony, from an interested party, about itself. It is not evidence, and a serious reviewer knows the difference.

The failure is not that your system is insecure. It is that its integrity is a claim you make about yourself, and the entire point of an audit is that such claims don't count.

What you'd have to build to fix it

This is the real build-vs-buy comparison — not "approval queue" (a week) but "approval queue whose output survives a hostile reader":

• Key management for every approver. Each human needs a private key they actually hold, that you never see, with enrolment, rotation, revocation, and recovery. This is the hard part, and it is hard forever.
• A canonical serialization. Byte-exact, cross-language, floats banned, stable under field addition — or your signatures stop verifying the first time someone adds a column.
• A signed sequence, to catch deletion. Otherwise a signed trail with the inconvenient event removed verifies perfectly. (Most vendors miss this too.)
• Signing in the approver's client, not on your server — a server that holds the human's key can forge her approval, which puts you right back where you started.
• A verifier a stranger can run, without your cooperation, or you've built a nicer receipt.
• An atomic budget guard, because check-then-act loses to concurrency and agents are the most concurrent thing you run.

That is not a week. It is a quarter, it is cryptography (where the bugs are silent and the reviews are brutal), and it is a permanent maintenance surface — and none of it is your product.

When to build it anyway

Because sometimes you should, and a page like this is worthless if it doesn't say so:

• Nobody will ever challenge the record. Covered above. Build it.
• Your agent's worst action is cheap and reversible. Blast radius is the whole calculus. If the agent's worst day is a wrong Jira ticket, a Slack button is over-engineering already.
• You're already deep in a policy engine (OPA, Cerbos, Permit.io, Oso) that does what you need. Keep it. Those are good products, they do fine-grained authorization properly — just know that their audit output is a database, so if you get the "prove it" question, that is the piece you'd bolt on. Possibly ours. Possibly your own; the format is open.
• You have a real cryptography team. Then build it. We'd genuinely like to compare notes, and the spec is CC BY 4.0 so you don't need our permission.

When to buy

• Your enterprise deals stall in security review and "we log approvals to Postgres" is the sentence that stalls them. This is the common one, and the cost is measured in delayed contracts, not in risk.
• You're chasing ISO 42001 / SOC 2 / a financial-controls audit and someone has asked how you evidence agent decisions.
• Your agent moves money, or touches production, or does anything you cannot take back.
• You want the approval to be non-repudiable against your own team. This one is uncomfortable and real: a control your own admins can forge is not a control against your own admins.

What we actually sell

The enforcement point, the human-signed approval, and the signed decision ledger.

The record format is an open spec (CC BY 4.0) and the verifier is Apache-2.0 with zero dependencies — so you can check every decision our product makes without running, buying, or believing our product. The control plane itself is commercial.

If that combination seems like a strange thing for a vendor to do: it's the only way the central claim — you don't have to trust us — can be anything other than marketing.

Verify one of our decisions in your browser → and then try to forge it. If it doesn't convince you, build the Slack button. It's a good design.