Responsible disclosure

If you believe you have found a security vulnerability in PAID, we want to hear about it. This page defines what is in scope, how to report, the safe harbor we extend to good-faith researchers, and what you can expect from us. It supplements our public security model, which documents both what is implemented and what is honestly still on the roadmap.

Last updated: 2026-07-06

Scope

The following properties are in scope:

Infrastructure operated by our sub-processors (Stripe, Plaid, Dwolla, ClearBank, Binance Pay, Circle, Sardine, Render) is out of scope here — report issues in those systems to the vendor's own disclosure program. If a vulnerability in our integration with a sub-processor exposes PAID data, that is in scope and we want the report.

How to report

Email [email protected]. This mailbox is the canonical intake channel for security reports. Please include:

• Affected host and endpoint — e.g. api.trustfabric.ai + the request path.
• Reproduction steps — exact requests, parameters, and preconditions. Raw HTTP traces or a proof-of-concept script are ideal.
• Observed vs. expected behavior — what happened and why you believe it is a security defect.
• Impact assessment — what an attacker could actually do with it.
• The account identifiers you used — so we can correlate against our audit ledger.
• A way to reach you — for follow-up questions and to coordinate disclosure timing.

One issue per report is easier for us to triage than a combined dump, but do not let that delay a report — send what you have.

Rules of engagement

Research qualifies as good-faith when it stays within these bounds:

• Test only against accounts you created yourself. Test-mode keys (sk_test_…) work against the live API — see the quickstart — so there is no reason to touch live-mode money paths.
• If you encounter another tenant's data (a tenant-isolation failure), stop immediately, do not download or retain it beyond the minimum needed to demonstrate the issue, and report it.
• Do not exploit a finding beyond what is needed to prove it exists — no pivoting, persistence, or data exfiltration.
• Do not degrade the service. The platform enforces per-IP and per-merchant rate limits; deliberately testing their exhaustion is volumetric testing and is out of scope.
• Keep the details confidential until we have remediated and agreed disclosure timing with you.
• Comply with applicable law.

Safe harbor

For security research conducted in good faith and within the rules of engagement above, we commit that we will not initiate legal action against you or refer you to law enforcement, and we consider such research authorized within the meaning of applicable anti-hacking and anti-circumvention law. If a third party pursues legal action against you for research that complied with this policy, we will make it known that your actions were authorized under this policy. This safe harbor does not extend to research that breaks the rules of engagement — in particular accessing or retaining other tenants' data beyond a minimal proof, or degrading the service for real users.

Out of scope

• Denial-of-service, volumetric, or rate-limit-exhaustion testing of any kind.
• Social engineering of PAID staff, merchants, or buyers (phishing, vishing, pretexting).
• Physical attacks against people, offices, or data centers.
• Vulnerabilities in sub-processor infrastructure (report to the vendor — see Scope above).
• Automated scanner output without a demonstrated, exploitable impact.
• Reports that a documented roadmap gap exists — the security model already discloses known gaps publicly. A working exploit against one of those gaps is in scope.

What to expect from us

• Acknowledgment — within one business day of receipt.
• Triage — we assess severity (CVSS-based) and confirm or decline the finding, and tell you which.
• Remediation — confirmed vulnerabilities follow the patching SLA documented in our internal security-posture audit, measured from disclosure:

We ask that you allow up to 90 days from your report before public disclosure. If we ship a fix sooner, we are happy to coordinate earlier publication. If we need longer (for example, a fix that depends on a sub-processor), we will tell you why and agree a revised date rather than go quiet.

Recognition

We do not currently operate a paid bug-bounty program, and this page does not promise one. Valid reports are recognized on request — we will credit you by name or handle once the issue is remediated, if you want the credit.

Machine-readable policy

An RFC 9116 security.txt is served at /.well-known/security.txt. It predates our domain migration to trustfabric.ai; where the two disagree, this page and [email protected] are canonical.

Related documents

• Security model — encryption, access control, and honest roadmap gaps
• Sub-processors — the third parties whose infrastructure is out of scope here
• Privacy policy — lawful bases, retention, data-subject rights
• Status + uptime — live platform status