Skip to content
Inkstand
Request an invite

legal

Security disclosure

How to report a flaw, what happens next, and what we undertake not to do to anyone who reports one in good faith.

Version 0.2Effective 29 July 20265 min readTouch Grass AB

Written from the system, not from a template. Every statement here describes what the software actually does — the region, the sub-processors, what is collected, what is retained, what leaves the EEA. It is a description of a system rather than legal advice, and it is published rather than sent after a call. If your counsel needs redlines, or your own paper, that is a conversation and not a problem.

▸Contents — 7 clauses
  1. 1How to report
  2. 2What happens next
  3. 3What is in scope
  4. 4What we ask you to do
  5. 5Safe harbour
  6. 6Recognition, and money
  7. 7Telling customers

1How to report#

1.1Send reports to security@touchgrass.consulting. If you would rather not use email, the invite request form reaches the same people — put the word SECURITY as the first line of the message. Either route is read by the people who build the product, and nothing sits in a queue on the way to them.
1.2Useful reports contain the affected URL or function, what you did, what happened, what you expected, and enough detail to reproduce it. A proof of concept is welcome. A scanner's output pasted whole is not a report and will be treated as one line.
1.3Report in whatever language you are comfortable in. English or Swedish will be answered fastest.

2What happens next#

  • Within three working days you get an acknowledgement from a person, not an autoresponder.
  • Within ten working days you get an assessment: whether it is reproduced, roughly how serious we think it is, and what we intend to do.
  • While we are fixing it you get an update at least every two weeks, or sooner if something changes.
  • When it is fixed you are told, and asked to confirm the fix if you want to.

If we decide not to fix something, you will be told that and told why, rather than hearing nothing. A decision you disagree with is a better outcome than silence.

These are targets rather than a contractual service level. They are what we intend to do and what you should hold us to; a contractual commitment on response times is agreed in writing with the customers who need one.

3What is in scope#

3.1In scope: this website, the Inkstand application, its server-side functions, and the database policies that enforce isolation between accounts. Anything that lets one account reach another's data — or one workspace reach another's inside the same account — is the most serious class of report there is here and will be treated that way.
3.2Out of scope: the managed database, authentication, storage and hosting platforms themselves, which have their own disclosure programmes and should be told directly. Also out of scope are findings in third-party model providers reached through the AI features.
3.3Already documented, so not a finding. Design decisions we have already published and answered are not discoveries. The questionnaire on the security page states our position on enterprise identity, session lifetime, network restrictions and the limits of the server-side URL fetch; a report restating one of those will be acknowledged and closed, as will reports of security headers we have deliberately not set, of email configuration on a domain that sends no mail, and of theoretical issues with no demonstrated impact.

4What we ask you to do#

  • Test only against workspaces and accounts you created. Do not access, modify or retain anybody else's data — if you do reach it, stop immediately, say so in the report, and delete what you retrieved.
  • Do not degrade the service. No load testing, no denial of service, no spam of the invite form or the sign-in flow, and no social engineering of anyone.
  • Do not use a finding for anything other than demonstrating it, and do not hold it for payment.
  • Give us ninety days before publishing, or less if we have fixed it sooner and agreed. If we go quiet on you for more than thirty days, treat that as our failure and publish.
  • Comply with the law. Nothing here authorises anything unlawful.

5Safe harbour#

5.1If you make a good-faith effort to follow this policy, we will treat your research as authorised. We will not bring or support a civil claim against you, we will not report you to law enforcement, and we will not treat your testing as a breach of clause 11 of the terms of service.
5.2If a third party brings a claim against you for research that followed this policy, we will make it known publicly and to them that it was authorised.
5.3What this cannot do. We can only waive our own rights. This is not immunity under criminal law in your country or in Sweden, and it does not bind our sub-processors, whose own programmes apply to their systems.

6Recognition, and money#

There is no bug bounty programme and no payment. If you would like credit, you will get it by name or handle wherever the fix is described, and you can decline. We will not make credit conditional on you signing anything or on you staying quiet, which is the practice that has made a lot of vendor disclosure programmes worthless.

7Telling customers#

Where a reported vulnerability affected personal data we process for a customer, that customer is notified without undue delay under clause 9 of the data processing agreement, in stages if that is faster than waiting for one complete account.

Vulnerability disclosure policy, version 0.2, effective 29 July 2026. Every agreement, and who you are contracting with, on the legal index.