Security and Responsible Disclosure

1. Reporting a vulnerability

Email [email protected]. This mailbox is monitored by the FinStream engineering team and is the single intake point for security reports — from customers, from independent researchers, and from platform partners including Anthropic.

A report is most useful when it includes:

• What you found, in one or two sentences.
• The exact URL, endpoint or assistant tool involved.
• Reproduction steps, and the account or organisation you used.
• What an attacker could achieve, and any evidence (a request/response pair, a screenshot, a short recording).
• How you would like to be credited, if you would like to be.

Please send security reports only to [email protected], not to the support mailbox and not through a public channel, so that a fix can ship before the issue is known. If you need to send a report encrypted, email us first and we will arrange a channel.

2. What to expect from us

• We acknowledge every report from a human being within 3 business days.
• We tell you whether we can reproduce it, and our assessment of severity, within 10 business days.
• We keep you updated while we work, and we tell you when the fix is deployed.
• We will credit you if you want the credit, and we will not name you if you do not.
• FinStream does not currently run a paid bug-bounty programme. We will say so plainly rather than leave a reward implied.

3. In scope

• The FinStream web application and its API at finstream.app and www.finstream.app.
• The supplier portal and the invitation and onboarding flows.
• The AI-assistant connector endpoint and its OAuth handshake.
• Anything that lets one organisation reach another organisation's data, lets a user exceed their role, or bypasses an approval, payment-release or accounting-close control.
• Authentication, session, token and password-reset weaknesses.

4. Out of scope, and things we ask you not to do

• Do not access, modify or exfiltrate data belonging to anyone but yourself. If you reach another organisation's data accidentally, stop, tell us, and delete what you retrieved.
• Do not run denial-of-service, volumetric or brute-force tests, and do not attempt to degrade the service for other customers.
• Do not social-engineer our staff, customers or suppliers, and do not attempt physical access to any facility.
• Do not test third-party services we depend on (our hosting, database, email, accounting or payment providers) — report those to the provider concerned.
• Reports that consist only of an automated scanner's output, a missing best-practice header with no demonstrated impact, a self-inflicted issue, a rate-limit observation, an outdated-browser dependency, or theoretical email spoofing on domains that publish a reject policy, will be closed with thanks and no action.

5. Safe harbour

If you make a good-faith effort to follow this page — you stay within scope, you avoid other people's data, you do not degrade the service, you give us reasonable time to fix the issue before disclosing it, and you do not extort us — then we will treat your research as authorised, we will not pursue or support a claim against you over it, and we will say so if a third party raises one. If you are unsure whether something is in scope, ask us first.

6. How FinStream protects customer data

• Encryption — Every connection is HTTPS. Data is encrypted in transit and at rest by our database and object-storage provider. Third-party credentials, such as an accounting connection's OAuth tokens, are encrypted with a dedicated key before they are stored.
• Tenant isolation — Every request is authorised server-side against the caller's organisation, company and role, and the database enforces organisation-level row-level security underneath as a second, independent layer. Neither layer is relied on alone.
• Authentication — Sessions and API tokens are asymmetrically signed (ES256) and verified against the published key set on every request. Assistant connections use OAuth 2.1 with PKCE; a user authorises their own assistant and can revoke it at any time.
• Authority separation — Spend approval, tax review, treasury release and accounting close are separate capabilities held by named people. Amounts above a configured threshold need two different approvers in sequence. No automated path grants any of these.
• Assistant surface limits — A connected assistant can read records and draft documents. Approving, releasing a payment, posting or closing a period, and deleting records are not available to it at all — those verbs do not exist on the connector. Every assistant call is rate limited per user and recorded.
• Audit trail — Approvals, submissions, issuances, releases and voids are recorded append-only with the acting user and timestamp, and are not pruned. Assistant tool calls are recorded with the tool name, the outcome and a SHA-256 hash of the arguments — never the arguments themselves — and those telemetry rows are purged automatically after 365 days.
• Secrets and access — Application secrets are held in the hosting platform's encrypted environment store, never in source control. Access to production data is limited to the people who need it to run the service.
• Change control — Changes ship through version control with automated type checking, linting, an automated test suite and architectural boundary rules that fail the build when a layer boundary is crossed.

7. Machine-readable contact

Our RFC 9116 security contact file is published at https://www.finstream.app/.well-known/security.txt and points at this page and the mailbox above.

8. Contact

• Security reports — [email protected]
• Everything else — [email protected]
• Postal address — 111255 PTE. LTD., 160 Robinson Road, #14-04 Singapore Business Federation Center, Singapore 068914