Vulnerability disclosure

Email [email protected] with “Security” in the subject line. It reaches the people who build this, not a queue, and we acknowledge a report within one business day.

If you would rather send the details encrypted, say so in the first message and we will arrange a key with you before you send anything sensitive. Please do not open a public issue, post the finding in a shared Slack channel, or send it through the contact form on this site.

Enough for us to reproduce it, which in practice means: the URL, endpoint or Slack surface affected; the steps, in order; what you expected and what happened; and the impact as you see it. A short proof of concept, a request/response pair or a screen recording is worth more than a paragraph of description.

Tell us the rough time of your testing and the account, organisation or workspace you tested from, so we can find it in our own records and separate your traffic from anybody else’s. If you would like credit, say how you want to be named.

• The marketing site, attesttag.com.
• The hosted console and its API — the deployment at app.attesttag.com, including the /v1 developer API, console API keys, and the MCP server at /mcp with the OAuth endpoints that connect clients to it.
• The Slack and Microsoft Teams apps themselves: anything that makes the bot read a conversation it was never invited to, answer with something the asking user could not see themselves, or act for a user who is not the one asking.
• The credential proxy: any way to make a connected service’s token, or any part of it, reach a model, a prompt, a log, an answer or another organisation.
• Tenant isolation: anything that lets one organisation read, change or infer another organisation’s channels, documents, connections, memories, routines or audit records.
• The confirmation path: a way to make a write, an approval or an access grant happen without the person who was supposed to confirm it — including through content the model reads, such as a document or a web page carrying instructions.

We will read anything you send, but these are unlikely to be treated as vulnerabilities:

• Scanner output with no working proof of concept, and version banners for dependencies with no demonstrated exploit path here.
• Missing headers, cookie flags or TLS configuration preferences that you cannot tie to a concrete impact.
• Denial of service, volumetric testing, and brute force against rate limits. Please do not run these at all — see the safe harbour below.
• Social engineering, phishing, or anything physical. Our staff and our customers’ staff are not targets.
• Vulnerabilities in Slack, your model provider, or another third party. Those belong in their own disclosure programmes; tell us too if the combination affects our users.
• Self-XSS, clickjacking on pages with no state-changing action, and content spoofing without a demonstrated consequence.
• A model answer that is wrong, biased, rude, or talked into ignoring its instructions where no security boundary is crossed. Persuading the bot to write a poem it was told not to write is not a vulnerability; persuading it to read a channel it is not in, reveal another organisation’s data, or perform a write nobody confirmed is one, and we want that report.

If you follow this policy, we will treat your research as authorised conduct. We will not bring a claim against you, we will not report you to law enforcement or ask anyone else to, and if a third party brings an action over research that followed this policy, we will say publicly that it was authorised.

Following the policy means, specifically:

• Test against an organisation and a Slack workspace or Teams organisation you control. Never against another customer's.
• Stop as soon as you can prove the issue. Do not read, copy, change or delete data that is not yours, and do not keep what you saw.
• Do not degrade the service: no denial of service, no load testing, no spam, no mass automated scanning.
• Give us a reasonable window to fix it before you tell anybody else.
• Follow the law where you are.

If you are part-way through and realise you have reached somebody else’s data, stop and tell us. Saying so is what keeps the safe harbour, not what loses it.

We acknowledge within one business day, and tell you our assessment of severity within five. After that you hear from us at least every fortnight until it is closed, without having to ask.

Our target for a fix, from the day we confirm it: seven days for anything critical — tenant isolation, credential exposure, unauthorised access to Slack content — thirty days for high severity, ninety for the rest. If we are going to miss one of those we will tell you before the date rather than after it, with the reason.

Where a fault affected a customer’s data, we notify the affected organisations. The data processing agreement is where that obligation is written down.

We would like ninety days from your report, or until a fix is released if that comes sooner, before the finding is made public — and we are happy to be told that is not enough time for something serious we are sitting on. We will not ask you to stay quiet indefinitely, and we will not ask you to remove a published write-up after the window. Tell us if you plan to publish and we will coordinate, including on what we say ourselves.

We do not run a paid bug bounty. We are a small team and would rather publish an honest “no” than a reward page nobody can collect on. What we do offer is a fast, human reply, credit on this page and in the release notes if you want it, and a straight answer about what we fixed and when.

Ordinary questions and problems go to support. For how the product is built to fail closed in the first place — the proxy that holds credentials, the human-in-the-loop writes, the audit trail — read guardrails. For what we hold and who processes it, the privacy policy and the subprocessor list.