Vulnerability Disclosure Policy

How to report a security issue, what's in scope, the safe-harbor terms, and our acknowledgement / triage / disclosure timelines.

Version 1.2 (August 29, 2026 — § 3(e) and § 6. The trust page told researchers Inscendo would "request that prosecutors do the same", and the Policy — the binding instrument — said no such thing. New § 3(e) states it: where a third party brings a claim, or a criminal referral or prosecution arises, from activity we determined was authorized, we take reasonable steps to make the authorization known and ask the prosecuting authority to do likewise. § 6 was a single sentence promising a hall of fame; it now states that consent comes first and silence means no listing, exactly what an entry shows (chosen name, date RESOLVED, severity band, general category), and what it deliberately withholds (endpoint, component, reproduction) with the reason — a category says what you did, a location tells the next attacker where to look. Technical detail goes to a § 7.8 advisory after the fix, linked from the entry. Adds an Inscendo obligation and narrows what we publish about a researcher; no researcher obligation is enlarged. Version 1.1 (August 29, 2026 — § 10 restated. It reproduced the contents of our `security.txt` and carried unresolved drafting placeholders in its Expires and Hiring lines, both of which were published. The stated expiry was also wrong: the file is served with a shorter expiry than twelve months, and `Hiring` is not published at all. § 10 now describes what the file contains rather than restating its field values, and names the file as authoritative where the two disagree, so the Policy cannot drift from it again. No change to scope, safe harbor, authorized conduct, reporting address, disclosure timelines, or any commitment made to a researcher.))Effective May 30, 2026legal/vulnerability-disclosure.md

Inscendo: Vulnerability Disclosure & Safe Harbor Policy

Effective Date: May 30, 2026 Version: 1.2 (August 29, 2026 — § 3(e) and § 6. The trust page told researchers Inscendo would "request that prosecutors do the same", and the Policy — the binding instrument — said no such thing. New § 3(e) states it: where a third party brings a claim, or a criminal referral or prosecution arises, from activity we determined was authorized, we take reasonable steps to make the authorization known and ask the prosecuting authority to do likewise. § 6 was a single sentence promising a hall of fame; it now states that consent comes first and silence means no listing, exactly what an entry shows (chosen name, date RESOLVED, severity band, general category), and what it deliberately withholds (endpoint, component, reproduction) with the reason — a category says what you did, a location tells the next attacker where to look. Technical detail goes to a § 7.8 advisory after the fix, linked from the entry. Adds an Inscendo obligation and narrows what we publish about a researcher; no researcher obligation is enlarged. Version 1.1 (August 29, 2026 — § 10 restated. It reproduced the contents of our security.txt and carried unresolved drafting placeholders in its Expires and Hiring lines, both of which were published. The stated expiry was also wrong: the file is served with a shorter expiry than twelve months, and Hiring is not published at all. § 10 now describes what the file contains rather than restating its field values, and names the file as authoritative where the two disagree, so the Policy cannot drift from it again. No change to scope, safe harbor, authorized conduct, reporting address, disclosure timelines, or any commitment made to a researcher.)) Provider: Inscendo Automation Inc.

We welcome reports from independent security researchers about vulnerabilities in our service. This Vulnerability Disclosure Policy ("VDP") describes how to report a vulnerability, what conduct we authorize, what conduct is out of scope, and how we will respond. This VDP is a unilateral commitment by Inscendo and is meant to encourage responsible disclosure.

This is not a paid bug-bounty program. We may, in our sole discretion, recognize researchers in a public hall of fame and provide modest tokens of appreciation.

1. Scope

1.1 In scope (assets we want you to test, within the limits of § 3)

The web application at https://inscendoiq.com and any sub-domain operated by Inscendo (our published security.txt is at https://inscendoiq.com/.well-known/security.txt)
The Inscendo public APIs, including the agent service endpoints
The Inscendo Browser Companion Chrome extension (v0.4.0 and later), installed in your own browser, attached to a tab in a domain you own
The capsule/widget/automation runtime as exposed to a tenant you own
Inscendo's authentication and authorization flows in your own tenant
Pre-deployment / staging environments only when explicitly identified as in-scope in our security.txt

1.2 Out of scope

Any third-party model provider's infrastructure (please report to the provider directly)
Microsoft Azure, Stripe, Cloudflare, GitHub, our AI and email providers, or any other sub-processor's infrastructure (please report to the operator), and any provider you connect yourself
Capsules, widgets, automations, or content created by other tenants of Inscendo
The mailbox provider or other vendors we use for operations
Domain-name infrastructure (DNS) operated by our registrar
Any site or domain not operated by Inscendo Automation Inc., including similarly named sites we do not control: do not test these under this VDP
Out-of-band scenarios: physical attacks, social engineering of Inscendo personnel, supply-chain attacks via packages we use

1.3 Reports we are not interested in (and that may be closed without action)

Reports generated solely by automated scanners with no demonstrated impact
Missing security headers absent demonstrated impact
Self-XSS or rate-limiting issues without demonstrated impact
Email-spoofing claims without proof of exploit
Reports that depend on outdated browser versions or lab-only configurations
Reports about social-engineering attack potential ("I could phish a user")
Reports about issues in third-party libraries we depend on, unless you also provide a working exploit against our deployed service
Brute-force or credential-stuffing reports against general account login (out-of-scope vs. an actual auth bypass)

2. Reporting

2.1 Where to report

Email: support@inscendoiq.com with "VULNERABILITY DISCLOSURE" in the subject line.

PGP encryption is encouraged. Our PGP key is published at https://inscendoiq.com/.well-known/pgp-key.asc (fingerprint 898A BDBE DF13 0DB5 5373 E6C4 EF9D 07D2 7D0B 6DA8).

2.2 What to include

A clear technical description of the vulnerability
A proof of concept (PoC) demonstrating exploitability: the smallest PoC sufficient to demonstrate impact
Affected URL, endpoint, file, or component
Affected version and environment (production, staging)
Step-by-step reproduction
Estimated impact, including data classes potentially affected
Any CVE/CWE references that apply
Your preferred public-acknowledgment name (or "anonymous")
Whether you intend to publish details, and on what timeline

2.3 What we commit to

Acknowledge receipt within five (5) business days
Triage and confirm or dispute within fifteen (15) business days
Communicate periodic status updates while the report is open
Notify you of remediation when complete
Recognize you (with your consent) on our public hall of fame
Not pursue legal action against you for testing within the scope of this VDP, subject to § 3

3. Authorized testing: Safe Harbor

If you make a good-faith effort to comply with this VDP, Inscendo will:

(a) consider your security research and vulnerability disclosure activities to be authorized under the Computer Fraud and Abuse Act, 18 U.S.C. § 1030, and analogous state laws;

(b) treat you as having authorization to access systems and data only as necessary to identify and demonstrate the vulnerability;

(d) consider you to be in compliance with the AUP § 1.4 (security testing prohibition), provided you operate against only the in-scope assets in § 1.1 and within the conduct boundaries in § 4.

(e) if a third party brings a claim against you arising from activity we have determined was authorized under this VDP, take reasonable steps to make known that your activity was authorized — and where a criminal referral or prosecution arises from it, request that the prosecuting authority do the same.

This safe harbor extends only as far as the conduct described in § 4 below. It does not extend to conduct that violates third-party rights, accesses third-party data without authorization, or violates law independent of the CFAA / AUP.

4. Authorized conduct: what you may and may not do

You may:

Test against your own tenant, your own browser session, and your own data
Make automated requests at a moderate rate (≤ 5 requests / second per endpoint)
Use accounts you have created yourself for the purpose of testing
Use the Browser Companion in a Chrome profile dedicated to your testing, attached to tabs of domains you own
Demonstrate authentication or authorization issues by accessing only the minimum data necessary to confirm the issue

You must not:

Access another tenant's data, except to demonstrate a cross-tenant isolation flaw, and only to the minimum extent necessary to confirm the flaw, with immediate cessation and reporting
Modify, exfiltrate, retain, store, or further disseminate any data you encounter (other than minimum necessary screenshots/excerpts for the report)
Run denial-of-service attacks or volumetric attacks
Perform credential-stuffing, password-spraying, or large-scale brute force
Perform social engineering against Inscendo employees, customers, or vendors
Perform physical attacks
Distribute malware, deploy backdoors, or modify Inscendo systems
Pivot from a vulnerability into deeper systems beyond the minimum needed to demonstrate impact
Withdraw, sell, or trade vulnerability information before disclosing to Inscendo
Demand payment in exchange for non-disclosure (this is extortion, see § 5.3)
Test against, or intentionally affect, any third-party service Inscendo integrates with
Attach the Browser Companion to any session containing data Inscendo's AUP (§ 1.7) prohibits processing

If you discover sensitive data (customer PII, secrets, tokens, encryption keys, etc.) during the course of authorized testing, stop, report immediately, do not retain, and do not further access.

5. Disclosure timing

5.1 Coordinated disclosure window. We request that you do not publicly disclose the vulnerability until we have remediated it or until ninety (90) days have elapsed from your initial report (whichever is sooner), to allow time for a fix.

5.2 Extension. If a fix is not yet possible at the 90-day mark and we are actively working in good faith on remediation, we may request a reasonable extension. Reasonable extensions will not be unreasonably denied by you.

5.3 No "extortion": what is and isn't allowed. Constructive negotiation about timing, coordinated disclosure, hall-of-fame recognition, and modest tokens of appreciation is welcome. Demands for payment, threats to disclose, or threats to sell the vulnerability to a third party are outside the safe harbor in § 3 and may constitute extortion or computer-fraud violations.

6. Recognition

Consent first. We publish nothing about you unless you have asked to be credited. Tell us in your report how you would like to appear — your name or handle, or "anonymous" if you want the credit without the name. If you would rather not be listed at all, say so, or say nothing: we fix the issue either way and you simply do not appear.

What we publish. With your consent, we list you on our acknowledgements page at https://inscendoiq.com/trust/vulnerability-disclosure, with: the name you chose, the date the issue was resolved, its severity band under § 8, and a general category (for example "Authorization" or "Prompt injection").

What we do not publish there. We do not list the endpoint, the component, the reproduction, or anything else that would point at where the weakness was. That is not to diminish your finding — it is because a category tells a reader what you did, while a location tells the next attacker where to look, including at code near the part we just fixed.

Where the detail goes instead. Where publishing the technical detail is worthwhile, we do it in a security advisory under § 7.8, after the fix is live and coordinated with you, and we link the advisory from your entry.

We may also, at our discretion, send modest tokens of appreciation (Inscendo swag, a thank-you note). This is not a payment or bounty.

7. Process

When we receive a report:

Acknowledge within 5 business days.
Triage: assign severity (Critical / High / Medium / Low / Informational), confirm reproducibility.
Open an internal ticket with researcher credit.
Communicate with the researcher about scope, timeline, and any clarifying questions.
Remediate: develop, test, and deploy a fix.
Notify: confirm remediation to the researcher.
Recognize: with researcher consent, publish on hall of fame.
Disclose: where appropriate, publish a security advisory.

8. Severity guidance (CVSS-style)

We use the following rough severity guidance to set priority. Final severity is determined by Inscendo:

Critical: remote code execution; cross-tenant data access; full account takeover via auth bypass; arbitrary file read on production; secrets exposure
High: privilege escalation; unauthenticated data exposure; SSRF reaching internal infrastructure; agent-tool authorization bypass
Medium: authenticated data exposure; CSRF on state-changing endpoints; reflected XSS in authenticated context
Low: open redirect; missing rate limit on a non-sensitive endpoint; improper session timeout
Informational: best-practice deviation, hardening recommendations

9. AI / Agent-specific reports

We are particularly interested in prompt-injection exploits against Inscendo IQ's AI tools — inputs that cause the agent to treat untrusted content as instructions, subvert its intended behavior, or write attacker-controlled content into tenant data. Well-documented, reproducible reports that pinpoint the specific tool or surface exploited are the most valuable; they help us map where these risks concentrate across the agent's tools and surfaces.

We also welcome:

Browser Companion authority escalation (e.g., bypass of sensitive-field sensor, attachment to a tab the user did not authorize)
Tool-use authorization bypass (e.g., causing the agent to call a tool the customer's permissions should forbid)
Confused-deputy / SSRF via tool calls to internal Inscendo infrastructure
Agent prompt-injection that causes the agent to exfiltrate secrets
Workspace sandbox escape out of the agent's isolated workspace

For AI-related issues, please describe the prompt or input you used, the model version (if known), and whether the issue reproduces deterministically.

10. `security.txt`

We publish a machine-readable security contact at https://inscendoiq.com/.well-known/security.txt, in the format RFC 9116 defines. It names the address to report to, links this Policy and our acknowledgements page, points to the PGP key in § 2.1, states the languages we read, and carries an expiry date that we refresh before it lapses.

That file is authoritative. If it and this section ever disagree, rely on the file: it is the copy machines read, and we keep it current.

11. Updates

We may update this VDP from time to time. The version posted at the time of your report governs that report.

12. Plain-English summary

Find a vulnerability? Email support@inscendoiq.com with "VULNERABILITY DISCLOSURE" in the subject.
Don't access other people's data, run DOS, or sit on it for ransom.
We won't sue you if you play by the rules.
We'll fix it. We'll thank you.
And if you pwn us? All your base are belong to us.

[End of Vulnerability Disclosure & Safe Harbor Policy]