Conto

Security

How we protect payments and records, and how to report a vulnerability.

How we protect your money and audit trail

Conto evaluates each control server-side and records it in a way you can verify later. For managed wallets, controls are enforced before funds can move. For self-custody wallets, the agent holds its own key, so Conto checks each payment before the agent pays and flags any settlement that does not match an approval.

  • Tamper-evident, append-only audit trail. Every payment decision, approval, and settlement is written to a per-organization SHA-256 hash chain. Database triggers reject updates and deletes, so the record is append-only at the database level. The decision and its audit entry commit in the same transaction, so a payment cannot change state without its matching record.
  • Verifiable integrity. Owners and admins can verify the hash chain for any date range and confirm that no entry was altered or removed.
  • Controls re-checked at execution. Spend limits, approvals, and trust checks apply before a payment moves, and the full policy set is evaluated again at execution time, so an approval cannot outrun a policy change.
  • Separation of duties. An agent cannot approve its own flagged payment. Approvals require a human with an approver role, and high-value actions can require more than one approver before a payment moves.
  • Sanctions screening. OFAC country and recipient-address checks can deny a payment that every configured policy would allow. No setting turns them off.
  • Data minimization. Audit responses and exports strip network and account metadata such as IP address, user agent, and raw internal state, so evidence you share carries the payment decision record and nothing more.
  • Encryption and isolation. Managed wallet private keys never reach Conto. Webhook and channel secrets are encrypted with AES-256-GCM, webhook payloads are signed, and each record is scoped to your organization.

The audit log guide documents the integrity model, the verification endpoint, and the export format in full.

How to report

Email security@conto.finance. Include reproduction steps, the affected URL or endpoint, the impact you believe the issue has, and any proof-of-concept code. Plain text is fine. Encryption is optional. If you want it, ask for our PGP key in your first message.

Please do not file public GitHub issues for suspected vulnerabilities. Please do not post details to social media or public forums until we have agreed on a coordinated disclosure date.

The machine-readable version of this policy is at /.well-known/security.txt per RFC 9116.

What you can expect from us

  • We acknowledge new reports within five business days of receipt.
  • We provide a triage update with a severity assessment within ten business days.
  • We work toward a fix on a timeline that matches the severity. Critical issues take priority over everything else on the roadmap.
  • We coordinate disclosure with you. If you would like attribution in a public advisory or release note, we are happy to do that.
  • We do not currently run a paid bug bounty. We do thank researchers publicly with their consent.

Scope

The following are in scope:

  • conto.finance and its subdomains operated by Conto.
  • The Conto SDK packages on npm (@conto_finance/sdk, @conto_finance/mcp-server, @conto_finance/create-conto-agent).
  • The Conto API surface, including webhook signing, SDK authentication, and policy evaluation.

The following are out of scope:

  • Findings that require non-default browser configurations, physical access, or social engineering of Conto staff.
  • Vulnerabilities confined to third-party services outside Conto's control. Please report those to the respective vendor. We will cooperate if the issue affects Conto users.
  • Best-practice findings without a demonstrated security impact (missing security headers on non-sensitive routes, lack of rate-limit on public marketing pages, theoretical CSRF on idempotent endpoints, and similar).
  • Denial of service via traffic volume, resource exhaustion, or application-layer flooding.
  • Reports from automated scanners with no manual validation of exploitability.

Safe harbor

If you make a good-faith effort to comply with this policy, we will not pursue or support legal action against you for your research. We consider activity that follows this policy to be authorized, and we will work with you to understand and resolve the issue quickly.

To stay within safe harbor, please:

  • Only test against accounts you own. Do not access, modify, or exfiltrate data belonging to other Conto customers.
  • Stop testing as soon as you confirm a vulnerability and report it. Do not pivot, escalate, or persist beyond what is needed to demonstrate the issue.
  • Do not run automated scans that could degrade service for other users.
  • Give us a reasonable amount of time to fix the issue before public disclosure.

If you are unsure whether a planned test would fall within this policy, ask first at security@conto.finance.