Inscendo: Vulnerability Disclosure & Safe Harbor Policy

Effective Date: May 30, 2026 Version: 1.4 (September 17, 2026 — § 6. Adds one optional item to what we publish: at the researcher's request, a link to their public profile on a well-known professional or security-research platform (personal websites and other addresses are not linked). The link is theirs, not ours; it is published only because they asked, it does not alter the non-endorsement statement introduced in version 1.3, and we may decline or remove a link that no longer resolves or that points at anything other than a personal profile. Adds no obligation on any researcher and publishes nothing without their request. Version 1.3 (September 16, 2026 — § 6. States what a listing on the acknowledgements page is and is not: an acknowledgement of a report we received and fixed, from an independent third party who is not affiliated with, employed by, or endorsed by Inscendo, and not a recommendation of their services. Adds no obligation on any researcher and narrows nothing we promised; it prevents the page being read as a partner or vendor list.) 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;

(c) not pursue civil or criminal claims against you for activity authorized under this VDP;

(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 a listing is. A listing is an acknowledgement of a report we received and fixed. Researchers are independent third parties who are not affiliated with, employed by, or endorsed by Inscendo, and a listing is not a recommendation of their services.

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").

A link, if you ask for one. If you would like your name to link to your public profile on a well-known professional or security-research platform (for example LinkedIn, GitHub, X, HackerOne, Bugcrowd, or Intigriti), give us the URL in your report or when you confirm your acknowledgement, and we will link it. We link only profiles on platforms of that kind, not personal websites or other addresses. The link is yours: it appears because you asked, it is not an endorsement or a recommendation of you or your services, and it changes nothing in the paragraph above about what a listing is. We may decline or later remove a link that does not resolve, requires a login, or points at anything other than your profile.

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:

1. Acknowledge within 5 business days.
2. Triage: assign severity (Critical / High / Medium / Low / Informational), confirm reproducibility.
3. Open an internal ticket with researcher credit.
4. Communicate with the researcher about scope, timeline, and any clarifying questions.
5. Remediate: develop, test, and deploy a fix.
6. Notify: confirm remediation to the researcher.
7. Recognize: with researcher consent, publish on hall of fame.
8. 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]