PromptHalo logo
PromptHaloTrust Center
← Trust Center Security overview
Published policy

Coordinated Vulnerability Disclosure Policy

How to report a security issue in a PromptHalo product, what protections apply to your research, and what we commit to in return.

Version 1.0 Effective September 4, 2026 Next review September 4, 2027 Classification PublicDistribution Public
Reporting an issue right now? Email security@prompthalo.ai. A person replies within 2 business days. Safe harbour applies from the moment good-faith research begins, so there is no need to read the rest of this first.

1 Purpose

PromptHalo builds security testing tools, so reporting a flaw in its own systems should be as straightforward as reporting one found with them. This policy sets out how to report a vulnerability in a PromptHalo product or system, what PromptHalo commits to in return, and the protections that apply to research conducted in good faith. It is a coordinated disclosure policy, not a bug bounty programme; see section 9.

2 Scope

In scope. Any system PromptHalo operates or controls:

  • The platform and its API
  • Published client libraries, agents and integrations
  • Cloud infrastructure, so far as it is reachable from the internet

Out of scope. These belong to others, so testing against them cannot be authorized here. Report them to the party that owns them:

  • Customer target systems. Systems the platform is pointed at belong to those customers
  • Third-party services. Cloud, identity and model subprocessors run their own programmes; the current list is available on request
  • Social engineering of staff, customers or vendors
  • Physical attacks against offices or personnel
  • Denial-of-service and volumetric testing of any kind

Generally not accepted without demonstrated security impact: missing security headers, weak TLS ciphers with no exploit path, self-XSS, clickjacking on pages with no sensitive action, unverified scanner output, and rate-limiting observations with no attack they enable.

3 Safe harbour

The commitment. Where research makes a good-faith effort to comply with this policy, we will treat it as authorized, we will not initiate or support legal action over it, and we will not report you to law enforcement. If a third party brings action against you for research within this policy, we will state publicly that your activity was authorized.

Good faith means, concretely:

  • Access, modify and retain only what demonstrates the issue. One record is proof; a thousand is exfiltration
  • On encountering personal data, customer content or credentials, stop, retain and transmit nothing, and describe what was found in general terms
  • Do not degrade, disrupt or reduce the availability of any service
  • Do not pivot further into the environment once impact is established
  • Allow reasonable time to remediate before publishing, per section 8

Safe harbour does not extend to activity unlawful independently of this policy, or to out-of-scope assets. It states how PromptHalo will act and cannot bind third parties.

4 How to report

Email security@prompthalo.ai. Anonymous reports are accepted; the only cost is that follow-up and credit become impossible.

A useful report includes:

  • The affected asset: URL, endpoint or component
  • Vulnerability type and, if available, a CVSS vector
  • Steps to reproduce, detailed enough to follow without guessing
  • Proof of impact: a screenshot, a request and response pair, or a short video
  • Prerequisites: authentication, role, tenant, timing
  • How you would like to be credited, if at all

Please do not open a public issue, post to social media, or file through a broker before making contact.

5 What we commit to

PromptHalo is a small company, so these targets are set at what a small team can hold every time rather than at what sounds impressive. They are commitments, not aspirations. Where one is going to be missed, you hear before the deadline rather than after it, with a reason and a new date.

Response stages, targets and what happens at each
StageTargetWhat happens
Acknowledgement2 business daysA person confirms receipt and gives you a tracking reference
Triage10 business daysThe issue is reproduced, severity assigned, and scope confirmed
Status updatesAt least every 30 daysUntil the issue closes, and whenever the status changes
RemediationBy severity, section 6A fix ships, or a documented compensating control with a dated plan
Resolution notice5 business days after the fixRemediation confirmed, and you are invited to verify
Disclosure90 days by defaultPublished as an advisory, coordinated with you

Grace period. Acknowledgement carries no extension. Triage and the resolution notice may each be extended once, by up to 5 business days, with notice before the original date giving the reason and the new date. A further extension needs your agreement.

6 Severity and remediation timelines

Scoring uses the current version of CVSS, and the response states which version was applied. Scores are adjusted for exploitability in this environment and blast radius across tenants. Where the assessment differs from yours, the reasoning is explained rather than the number quietly reassigned.

Severity is assessed against attack paths, not standalone scores. What matters is the preconditions an attacker must already hold, the trust boundaries a finding lets them cross, and what becomes reachable next. A Medium finding is treated as Critical where it opens a path to cross-tenant access, to credential or token material, or to an agent’s tool and data permissions. Several findings that compose into one path are scored as the path. The reverse applies too: where a high base score is unreachable because an upstream control holds, severity is lowered and the specific control named, so you can say if that is wrong.

Severity bands, CVSS ranges and remediation targets
SeverityCVSSTargetTypical examples
Critical9.0 to 10.07 daysCross-tenant data access, remote code execution, authentication bypass
High7.0 to 8.945 daysPrivilege escalation within a tenant, stored XSS with session impact, SSRF reaching internal services
Medium4.0 to 6.990 daysReflected XSS, CSRF on a state-changing action, disclosure of non-sensitive internals
Low0.1 to 3.9Next scheduled releaseLimited impact requiring unlikely preconditions

An actively exploitable critical finding takes precedence over planned work, and the clock starts at triage rather than the next sprint boundary. Targets are measured to a shipped fix or to a documented compensating control; where a fix depends on an upstream provider, that dependency is named in the status update.

Grace period. A remediation target may be extended once: by up to 7 days for Critical, and up to 30 days for High, Medium and Low. Notice comes before the target date and states the reason, the mitigation holding in the meantime, and the new date. A second extension needs your agreement. Extending a remediation target does not extend the disclosure date in section 8, which moves only by the separate request set out there.

7 AI-specific findings

Some reports concern model behavior rather than conventional application security. These are accepted and triaged, with one distinction:

  • In scope: prompt injection that crosses a trust boundary, causing the platform to act outside an authorized test scope, leak another tenant’s data, or exfiltrate credentials or system prompts with security value. Also jailbreaks that defeat a publicly asserted control, and any path by which test data reaches a model provider contrary to stated terms
  • Not a vulnerability: eliciting objectionable, inaccurate or off-policy text with no security consequence. That is a quality issue, welcome but not handled as a security finding

The dividing line is whether the behavior breaches a security boundary or a promise made on the Trust Center.

8 Coordinated disclosure

The default is publication at 90 days from triage, or the day a fix ships, whichever comes first.

An extension is requested only where remediation genuinely requires it, such as a coordinated fix with a third party or a change that cannot ship safely inside the window. The reason and a proposed date are given, and silence is not treated as consent.

Advisories appear in the Advisories section of the Trust Center and are notified to affected account administrators. A CVE is requested where a finding warrants one. Reporters are credited by name or handle unless they ask otherwise.

Where an issue cannot be reproduced, or is assessed as accepted risk, you are told plainly with the reasoning. You remain free to publish; the only request is that our position is represented accurately.

9 Recognition

There is no paid bug bounty at present. PromptHalo is a small company and prefers to promise what it can deliver: fast acknowledgement, honest triage, remediation on published timelines, and public credit.

Researchers whose reports lead to a fix are credited in the resulting advisory and in the acknowledgements. A paid programme, if introduced, will be announced here first.

10 Contact

One address covers everything: security@prompthalo.ai. For an active incident affecting your data, put INCIDENT in the subject line. Document requests and trust desk questions go to the same address, answered within 2 business days. Encryption details are in section 4.

PromptHalo Technologies, 6475 Preston Rd, Unit 140, Frisco, TX 75034, USA.