Loading…
Compare
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 either cites a versioned public package artifact or states that public evidence is unavailable — verify the boundary 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 — a working build, in App Store review, not yet publicly downloadable, and not yet on Google Play. What’s live today, from published npm artifacts, is the receipt verifier and MCP proxy human-approval gate. A public plain-HTTP hold/approve example is not currently served, so this page makes no implementation-status claim for that path. There is no hosted NOA relay yet.
A 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.
No. 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".
None. 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.
Yes — Telegram’s Bot API is plain HTTP (webhooks or long-polling), so any language can drive a bot.
Current public package artifacts do not include a plain-HTTP hold/approve example or implementation. This page makes no implementation-status claim for that path and does not credit it as publicly evidenced.
The 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).
This 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). Working builds were submitted to the App Store and Google Play on 2026-08-11 and are pending store review — neither can be downloaded until the stores approve. Until they ship, the published MCP proxy documentation describes using `noa-approve` for its human-approval gate. No public plain-HTTP example is claimed here.
Yes — 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 relay is software you run in your own environment. That statement covers the published MCP proxy; this page makes no public plain-HTTP relay claim. Not shipped. There is no run-it-for-you hosted gate service today — the gate runtime and relay are software you run in your own environment. The hosted admin console (the management surface you sign into) is live in beta and is a different thing.
Read the published artifacts. Run the verifier yourself. Verify the receipt offline.
Apache-2.0 package artifacts are public. The receipt format and MCP proxy docs are linked here; no public plain-HTTP gate source or example is claimed.