Security & trust

Security

Cosignet is a control for high-risk AI-agent actions, so we state plainly what we guarantee, what we store, and how to reach us. We describe cryptographic binding — not unbreakable security.

Who runs this: meet the founder.

Contact & responsible disclosure

Report a vulnerability to security@cosignet.com. Please include steps to reproduce and impact. We aim to acknowledge within a few business days. Test only against your own account and data; do not access other tenants' data, run denial-of-service, or spam real approvers. We will not pursue good-faith research that follows these rules.

Machine-readable policy: /.well-known/security.txt.

Approval integrity

• Every approval requires WebAuthn user verification (UV). Depending on the device and authenticator, this may use biometrics, PIN, passcode, or a security-key interaction.
• The signing challenge is nonce ‖ SHA-256(payload), so the signature is bound to the exact action. Change any field after approval and the signed decision no longer matches.
• The approval page re-hashes the displayed data in the browser and confirms it's exactly what you'll co-sign when it equals the signed fingerprint — protection against UI spoofing.
• The passkey private key is generated and protected by the approver's authenticator. On many platforms this uses secure hardware such as Secure Enclave or TPM. Cosignet never receives or stores it.
• One-time challenges; assertions are bound to the challenge and cannot be replayed against a different payload.

Fail-closed by default

No signature, no approval. If the human does not approve, the request expires and your integration receives a non-approved decision (pending, rejected, or expired) — never approved. Your code should proceed only on an explicit approved status, so a timeout or outage fails safe.

Read Availability and failure modes, or check live status at status.cosignet.com.

Data handling

• We do store the action payload. It is required to show the approver exactly what they are signing and to compute the binding hash. Cosignet is not a hash-only relay. Keep secrets out of payloads — pass references (IDs) instead of raw sensitive data.
• We store the raw WebAuthn assertion as the audit trail (proof a specific credential approved a specific payload), plus metadata: timestamps, status, credential ID, and the payload's SHA-256.
• Transport is HTTPS only; HSTS is enforced. Data is held in Cloudflare D1.
• API keys are stored only as a SHA-256 hash and a short prefix; the full key is shown once at creation and never again.

Approval link privacy

Approval links are private by default. Anyone who opens the link sees only that an approval is being requested — the action label and payload stay hidden until the approver proves who they are.

• Private (default): reading the payload requires a passkey view ceremony — the approver's own device unlocks the details before they sign. Rejecting also requires that verified view session, so a stranger with the link can't reject on the approver's behalf. A leaked link reveals nothing and can't act.
• Public (opt-in): a customer can switch an account to public link mode, which exposes the action and payload to anyone with the link — useful when the approval is meant to be openly reviewable. This is a deliberate capability you turn on, never the default.

Link privacy is separate from the public transparency reveal below: link mode controls who can read a live request; public reveal permanently publishes an approved action into the append-only log.

Audit trail & retention

Each confirmation keeps its action, payload, hash, status, and (once approved) the raw assertion, viewable in the dashboard. We do not yet run automatic deletion; data is retained until you request removal. For deletion, export, or data-residency questions, contact security@cosignet.com. Configurable retention and regional storage are on the roadmap for Enterprise.

Public transparency log

Approvals are recorded in an append-only transparency log, in the spirit of Certificate Transparency. Each approval is a tamper-evident leaf in a Merkle tree, and we publish a signed tree head. Anyone can request an inclusion proof that a specific approval is committed under a published root — the audit trail is verifiable independently, not just on our say-so. Verify an approval →

• Leaves bind the same data the approver signed (payload hash, credential, timestamp), so the log inherits the cryptographic binding.
• Independently checkable signatures: the tree head is signed with Ed25519; the public key is published at /public/log/key. Open-source verifier scripts (Node + Python) check the full chain.
• Public anchoring: each tree head is anchored into Bitcoin via OpenTimestamps — a trust-minimized anchor, so the log's integrity does not depend on trusting us or any single provider.
• Monitors can fetch consistency proofs between tree heads to confirm the log only ever appended (never rewrote history).
• Optional public reveal (off by default): a customer can opt an individual approval into public reveal. Its action and payload then become readable in the verification bundle — verifiable against the hash the approver's passkey actually signed, so it's a strong, passkey-bound disclosure — and a slow PBKDF2 hash of the account's designated verified email is committed into the leaf. This is the customer-selected accountable party, not necessarily the individual signer. The email hash is attested by our signed tree head (operator attestation, not signed by the passkey), and because email is low-entropy it can be confirmed by guessing a known address. Public reveal is permanent and irreversible, so it is opt-in per request — keep secrets out of payloads.

Infrastructure & sub-processors

We run on a small, audited set of providers:

• Cloudflare — hosting (Workers), database (D1), email routing, and Turnstile bot protection.
• Resend — delivery of transactional email (invites, magic links, notifications).
• Telegram — only if you link Telegram notifications; the action label and approval link are sent to your linked chat.

Full data-processing details, legal bases, and your data-subject rights are in the Privacy Policy.

Compliance status

Cosignet is in early access. We are not yet SOC 2 or ISO 27001 certified, and we don't claim to be — we'd rather state the posture plainly. Formal certification and contractual SLAs are on the roadmap for Enterprise. For a security review or questionnaire today, contact security@cosignet.com.

Put a signed approval in front of your riskiest actions

Free to start — no credit card.