Compare
Telegram tells you. NOA stops it, gets a human to approve it, and leaves a receipt.
If your agent is steered by a Telegram bot today, this is the same idea — a notification about a risky action — pushed one step further: the action is held, a human’s approval is cryptographically bound to that exact action, and what happened is left as a receipt you can verify offline. Every “NOA” cell below cites the exact checked-in source it comes from — verify it yourself instead of taking our word for it.
This is a comparison of gates, not a Telegram integration
NOA does not plug into Telegram today, and nothing here claims Telegram bots are insecure by design — the comparison is about what a chat message can and can’t cryptographically prove. The polished, one-tap phone-approval app is in alpha — proven end-to-end on-device, not yet published to the App Store or Google Play. What’s live today, from npm or from source, is the governance core underneath it: the MCP proxy’s human-approval gate and the plain-HTTP hold/approve gate below. There is no hosted NOA relay yet — every gate on this page is one you run yourself.
Notice that a risky action is about to happen
ShippedA chat message tells you the agent wants to do something — usually free text, whatever the bot author chose to print.
A notification tells you the same thing — plus a machine-checked risk-class label (LOW / MEDIUM / HIGH / CRITICAL / IRREVERSIBLE) attached to the action before it runs, not after.
Is the "approve" bound to the exact action?
ShippedNo. Tapping an inline-keyboard button sends the bot a callback_data token, not a signature over the action’s parameters. Whatever the bot code decides that token means, that’s what happens — the tap itself proves nothing about which parameters were approved.
Yes. A held action’s exact parameters are hashed into paramsHash, and paramsHash is one of the fields that gets Ed25519-signed when a human approves — the signature covers this call, not just "a call".
Offline-verifiable, tamper-evident record afterward
ShippedNone. Whatever your bot framework happens to log, if anything — not hash-chained, not independently verifiable.
A signed, hash-chained receipt for every decision (DEFERRED → ALLOWED → EXECUTED). Verify a chain completely offline, no NOA account, no network call.
Works for a Python daemon, cron job, or shell script (not Node, not MCP)
ShippedYes — Telegram’s Bot API is plain HTTP (webhooks or long-polling), so any language can drive a bot.
Yes, the same idea: create a hold with a plain POST, long-poll for the signed verdict, verify offline — curl and pure-Python examples included, no SDK required. Today this is a relay you self-host on your own machine (loopback by default), not a hosted service.
Who holds the approval key
ShippedThe bot token lives wherever the bot process runs; whoever holds that token (or can reach the right chat) can trigger an approval — there is no separate, cryptographic approver key.
The approver’s private key signs locally; the gate only ever verifies against a public keyring — it never needs the private key. A leaked private key is still the real risk to protect against (this is a key-custody problem, not solved by the format itself).
A one-tap mobile approval, no terminal required
AlphaThis is what a Telegram approval already feels like today — one tap in a chat you already have open.
A dedicated approval app (on-device Ed25519 key, a human looks at the request and taps approve/deny) is in alpha — not yet published to the App Store or Google Play. Until it ships, approving a hold means running the approver side yourself: the headless auto-approver in the HTTP example, or `noa-approve` for the MCP gate.
A hosted relay you don’t have to run yourself
RoadmapYes — Telegram’s own infrastructure hosts the Bot API for you; there’s nothing to stand up.
Not shipped. There is no hosted NOA relay today — the MCP proxy and the plain-HTTP relay above are both things you run in your own environment. A hosted control plane is on the roadmap, not a claim about what’s available now.
Read the gate’s code. Run it yourself. Verify the receipt offline.
Open-source, Apache-2.0. The receipt format, the risk-class labels, and both human-approval gates — MCP and plain HTTP — are all public.