Version: 2026-07-30 · v1.0
HarnessRouter Security and Vulnerability Disclosure Policy
Scope: This public policy defines the systems we authorize for good-faith security research, the rules for that research, how to report findings, and our limited safe harbor.
Block 1. Scope and Exclusions
1.1 Purpose and no bug bounty
Lumentree Corporation, a California corporation ("Lumentree," "we," "us," or "our"), welcomes reports that help protect HarnessRouter and its users.
This is a vulnerability disclosure policy, not a bug bounty program. We do not promise payment, rewards, swag, public credit, or any other compensation. Do not incur costs expecting reimbursement. If we later offer a separate bounty for a defined program, only that program's written terms will govern eligibility and payment.
This Policy is a public authorization and reporting process within the limits stated below. It does not form part of the HarnessRouter Agreement and is not intended to create a bilateral contract for services.
1.2 In-scope assets
Only the exact assets listed in the current table are in scope. A corporate name, shared cloud account, certificate, IP range, repository organization, dependency, or DNS suffix does not bring every related system into scope.
| Asset or hostname | Environment | Permitted test accounts or tenant | Permitted interfaces | Special limits |
|---|---|---|---|---|
| The HarnessRouter website (harnessrouter.ai), the HarnessRouter application, and the HarnessRouter API | Production | Only accounts, Workspaces, and tenants you own or are expressly authorized to use | The web application and the documented API endpoints reachable through the assets above | No high-volume automated scanning; see Sections 2.1–2.3 for method limits and stop conditions |
In-scope vulnerability classes are those that could materially affect the confidentiality, integrity, availability, authentication, authorization, tenant isolation, or secure operation of an in-scope asset. Examples include broken or missing access controls, authentication or authorization flaws, failures of tenant isolation, injection and similar input-handling flaws, insecure handling or exposure of secrets or credentials, and exposure of nonpublic data, in each case affecting an in-scope asset.
1.3 Excluded assets and activity
Unless separately authorized in writing by the system owner, the following are out of scope:
- any domain, subdomain, API, application, repository, mobile app, environment, IP address, or system not precisely listed in Section 1.2;
- third-party Providers, cloud services, payment processors, identity providers, model providers, Harnesses, Tools, MCP servers, Skills, connectors, package registries, and other vendor systems, even if accessible through HarnessRouter;
- Customer systems, Customer Applications, Workspaces, accounts, data, repositories, domains, databases, or infrastructure that you do not own or have the Customer's express authorization to test;
- employee, contractor, Customer, Authorized User, End User, or third-party devices and accounts;
- production data belonging to another person or tenant; and
- AI safety or model-behavior issues that do not demonstrate a security vulnerability in one of our in-scope assets. Section 3.4 explains where to send those reports.
Testing your own Customer Application or third-party system does not authorize testing our systems, and this Policy does not grant permission on behalf of a Customer or third party.
Block 2. Research Rules
2.1 Good-faith research
To qualify as good-faith research under this Policy, you must:
- test only an asset and interface expressly listed in Section 1.2;
- use only accounts, Workspaces, tenants, content, and data you own or are expressly authorized to use;
- make a reasonable effort to avoid privacy violations, degradation, disruption, destruction, loss, financial harm, and access to another person's data;
- use the minimum requests, accounts, privileges, data, and time necessary to confirm the issue;
- stop and report promptly when a vulnerability is reasonably demonstrated;
- comply with the stop conditions and data rules below;
- report through Block 3 before public disclosure and coordinate in good faith; and
- not exploit a vulnerability beyond what is necessary to establish its existence and impact.
Security testing that uses automated scanning or high-volume techniques is not authorized unless you first obtain our prior written authorization at contact@harnessrouter.ai. Any authorized automated security testing must keep request volume low enough to avoid degradation, instability, or disruption of an in-scope asset. This restriction does not apply merely because ordinary product use or non-security benchmarking or evaluation is automated, provided that activity complies with the HarnessRouter Agreement, Documentation, quotas, and rate limits and is not intended to identify or exploit a security vulnerability. Nothing in this paragraph authorizes stress testing, load testing, resource-exhaustion testing, or rate-limit testing prohibited by Section 2.3.
2.2 Stop conditions and minimization
Stop testing immediately if you encounter or can access:
- Personal Data, Customer Content, secrets, credentials, tokens, payment data, private communications, source code, files, Artifacts, Traces, or other nonpublic information that is not yours;
- another account, Workspace, tenant, database, or system;
- the ability to alter, delete, send, publish, purchase, deploy, transfer funds, change permissions, or take another external action for someone else;
- service instability, elevated error rates, resource exhaustion, or a risk of harm; or
- evidence of active compromise, ongoing attack, child sexual abuse material, or an imminent threat.
Do not continue to enumerate records or accounts. Do not take screenshots containing more data than needed. Record only the minimum identifiers necessary to explain the boundary, report through Block 3, and wait for instructions.
2.3 Prohibited methods
The following are not authorized:
- denial of service, distributed denial of service, stress, load, resource-exhaustion, queue-flooding, or rate-limit testing;
- social engineering, phishing, pretexting, credential stuffing, password spraying, MFA fatigue, or targeting people;
- physical intrusion, device tampering, office access, surveillance, or threats;
- malware, ransomware, destructive payloads, cryptomining, botnets, data corruption, or destructive file operations;
- persistence, backdoors, web shells, additional accounts, privilege retention, lateral movement, or maintaining access after the test;
- accessing, downloading, changing, deleting, decrypting, transferring, or retaining another person's data;
- testing live payment methods or causing charges, refunds, disputes, payouts, purchases, resource costs, or financial transactions;
- evading security controls to conceal identity or activity, altering logs, or interfering with monitoring;
- extortion, coercion, ransom demands, sale of access or data, or conditioning non-disclosure on payment;
- public disclosure before coordinated disclosure under Block 3; and
- any conduct prohibited by law or outside the express authorization in this Policy.
2.4 Data handling
Do not include live credentials, exploit tokens, Personal Data, Customer Content, or unnecessary production data in a report. Use redacted examples and synthetic test data where possible.
If you inadvertently obtain nonpublic data:
- stop immediately;
- do not copy, download, share, use, or further access it;
- preserve only the minimum evidence necessary to identify the issue;
- encrypt the report in transit using the method in Section 3.1, if available;
- tell us what was accessed, when, and whether any copy exists; and
- securely delete all retained copies after we confirm receipt or sooner if instructed, subject to any legal preservation direction.
Coordinate secure-report transport and evidence handling with us at contact@harnessrouter.ai; on request, we will provide any then-current secure-submission method and evidence-handling and deletion-confirmation instructions before you send sensitive details.
Block 3. Reporting and Coordinated Disclosure
3.1 How to report
Send reports to contact@harnessrouter.ai.
Encryption option: if you require encrypted transport, request our current secure-submission method at contact@harnessrouter.ai before sending sensitive details.
Include:
- the exact affected asset, URL, endpoint, parameter, feature, and environment;
- vulnerability type and expected security boundary;
- clear, minimal reproduction steps;
- a proof of concept using your own account and synthetic data where possible;
- observed and potential impact, including affected roles and tenant boundary;
- date, time, source IP or test-account identifier if useful for log correlation;
- whether you accessed any nonpublic data and how you handled it;
- any temporary mitigation you recommend;
- whether you plan to seek public credit or disclose the issue; and
- a safe way to contact you.
Do not send a security vulnerability through a public issue, community forum, social-media post, ordinary support channel, or copyright complaint.
3.2 Our process
We will use reasonable efforts to:
- acknowledge a report through the actual maintained channel;
- triage scope, reproducibility, impact, and data exposure;
- request additional information where needed;
- investigate and prioritize remediation based on risk;
- provide status updates when reasonably practicable; and
- coordinate disclosure and credit where appropriate.
Acknowledgment, triage, updates, and remediation are handled on a best-effort basis, and we do not commit to a fixed acknowledgment, response, or remediation time. This Policy does not promise a particular classification, fix, release, response time, or outcome.
3.3 Coordinated disclosure
Please give us a reasonable opportunity to investigate and reduce risk before public disclosure. We will work with you on a disclosure plan based on severity, exploitation risk, affected users, remediation complexity, upstream dependencies, and public interest.
We will not require indefinite secrecy as a condition of good-faith treatment. Do not disclose exploit code, credentials, Personal Data, Customer Content, or details that would create a material unresolved risk. Any requested publication date, attribution, advisory, identifier, or joint statement is agreed with you on a case-by-case basis and is not guaranteed by this Policy.
If a vulnerability affects a third party, we may coordinate with that party. This does not authorize you to test that party or disclose its information.
3.4 AI safety and model behavior routing
Report a traditional security vulnerability here when it shows unauthorized access, data exposure, authentication or authorization failure, tenant escape, prompt or tool injection that crosses a real security boundary, code execution, credential compromise, or another security impact in one of our in-scope assets.
Report harmful model behavior, jailbreaks, bias, hallucinations, policy-violating Output, evaluation concerns, or general AI safety issues that do not cross a security boundary to contact@harnessrouter.ai. Reports that concern a third-party model or Provider may also need to be sent to that Provider under its own policy.
When uncertain, use the security channel and label the report "AI safety routing requested." Do not test with real prohibited sensitive data or cause external Agent actions merely to classify the issue.
Block 4. Limited Safe Harbor
4.1 Conditions
This limited Safe Harbor applies only if you:
- act in good faith and comply with every material requirement of Blocks 1 through 3;
- remain within the precisely listed in-scope assets and methods;
- avoid harm, privacy violations, persistence, and prohibited conduct;
- stop on encountering another person's data or systems;
- report promptly and coordinate disclosure; and
- do not use the research as a pretext for extortion, commercial exploitation, or unrelated access.
Conduct outside those conditions is not authorized by this Policy.
4.2 Our four safe-harbor commitments
For qualifying good-faith research, and only to the extent of our own rights and authority:
- CFAA authorization. We consider the research authorized under the Computer Fraud and Abuse Act for the in-scope assets, interfaces, methods, accounts, and time reasonably necessary to perform research permitted by this Policy. We will not initiate or support legal action under the CFAA for accidental, good-faith violations of this Policy that do not materially exceed that authorization and that you promptly report and remediate as directed.
- DMCA § 1201. We will not bring a claim under 17 U.S.C. § 1201 for circumvention of a technological measure on one of our in-scope assets when the circumvention is undertaken solely as necessary for and in compliance with the good-faith research authorized by this Policy. This statement does not grant rights in third-party technology or content.
- Terms use-restriction waiver. We will not assert a breach of the use restrictions in our Terms of Service based solely on conduct that is necessary for and fully compliant with the good-faith research authorized by this Policy. All unrelated obligations and activity outside scope remain unaffected.
- Good-faith recognition. We will recognize research that complies with this Policy as helpful, lawful-intent security research and will seek to resolve uncertainty with the researcher before pursuing action where reasonably practicable.
4.3 Limits of the Safe Harbor
This Safe Harbor is a limited statement by us about how we will treat qualifying research. It is not:
- permission from, or a commitment by, a Customer, Provider, vendor, owner of third-party data or systems, law-enforcement agency, prosecutor, regulator, or government;
- immunity from criminal, civil, regulatory, contractual, employment, or other consequences imposed by anyone other than us;
- authorization to access third-party or Customer systems or data;
- a waiver of claims for conduct outside this Policy, intentional harm, extortion, data misuse, or continued access after a stop condition;
- a license to intellectual property or confidential information except the narrow access authorization stated above;
- a bug bounty or promise of payment; or
- a bilateral contract for research, remediation, disclosure, compensation, or services.
If a third party initiates legal action concerning qualifying research, we may, where legally permitted and appropriate, state that the research complied with this Policy. We cannot bind the third party or government.
4.4 Eligibility, law, versions, and changes
You remain responsible for complying with laws that apply to you, including sanctions and export-control restrictions. Any employee, contractor, or person with a separate confidentiality or access obligation must also comply with that obligation and may need written authorization beyond this public Policy.
The version in effect when research begins governs our treatment of that research, provided the research continues without a material break and the researcher complies with that version. We may update this Policy prospectively and will make the current and prior published versions of this Policy available through the Legal Hub or on request at contact@harnessrouter.ai. A later narrowing will not be used retroactively against research that was authorized and conducted in good faith under the prior published version.
For scope questions before testing, contact contact@harnessrouter.ai. Silence, an automated reply, or a support response does not expand the listed scope.
