Blog · Comparison
Slack approval buttons vs payload-bound approvals
Posting an Approve / Reject button to Slack is the most common way teams add a human step to an automation. It’s a fine notification. As the security gate on an AI-agent action, a typical implementation has a specific gap: it does not produce portable cryptographic evidence of what was approved.
A well-designed native approval can pause and bind a specific tool call inside its own platform. This comparison is about the common chat-button pattern and what Cosignet adds outside the platform that requested the decision.
What a Slack button actually proves
A typical Slack approval flow proves that a person (or whoever holds that Slack account) clicked a button at a point in time. Implementers can bind that click to backend state, but the binding is application-specific and usually remains dependent on platform and application logs. For a high-risk action that leaves three things open:
- No portable binding by default. A basic click is not cryptographically tied to the exact recipient, amount, endpoint, or command in a form an independent party can verify later.
- Platform-account evidence. A Slack click is an app event on a chat account, not a WebAuthn signature from an enrolled credential. Its evidentiary strength depends on Slack and application logs.
- Platform-scoped audit trail. The record usually stays inside the chat/workflow system rather than travelling with the action as a vendor-independent evidence artifact.
What payload-bound approval adds
Cosignet keeps the human step but changes what the human signs. The approver confirms with a device passkey, and the WebAuthn signature covers a challenge built from the action itself:
challenge = nonce ‖ SHA-256(payload)Now the approval is inseparable from the operation. Change any field afterward and the signature no longer matches. The result is evidence about one specific action, signed by a key that never leaves the approver’s device, with biometric or PIN user verification required.
Side by side
| Property | Slack Approve button | Cosignet (payload-bound) |
|---|---|---|
| Bound to the exact action | Implementation-dependent; not cryptographic by default | Yes — signature over nonce ‖ SHA-256(payload) |
| Proof of approver | Platform account event | Enrolled WebAuthn credential with user verification; real-world identity depends on enrollment |
| Resists post-approval drift | Implementation-dependent; only if execution re-checks the approved state | Yes — altered payload breaks the signature |
| Independently verifiable audit trail | Usually no — depends on platform/application logs | Yes — public RFC-6962 transparency log + open verifiers |
| Works behind NAT / firewall | Needs Slack connectivity | Yes — long-poll over your outbound connection |
| Notification UX | Native in Slack | Web Push, Telegram, email, or Slack link |
When a Slack button is fine
Honesty matters: if the action is low-risk, easily reversible, and you only need a heads-up plus a quick ack, a Slack button is the right amount of friction. A platform-native approval may also be enough when all execution and evidence stay inside that platform. Reach for payload-bound approval when the action is irreversible (deploys, fund transfers, data deletion, secret rotation, admin commands), when you need an audit trail that holds up later, or when an AI agent — not a fixed script — is choosing the arguments.
Cosignet is an approval and evidence layer, not an executor or policy engine: it doesn’t run the action or replace your existing controls. It makes the human decision real. For the broader picture, see human-in-the-loop for AI agents.