PARTNERS

Add selected Workbench capabilities through bounded OEM and partner integrations

aisecurity.llc

Vulnerability Disclosure Policy

We welcome good-faith reports of vulnerabilities in aisecurity.llc systems. This policy explains what is in scope, what is out of scope, how to report issues safely, and what testing is not authorized without written permission.

Responsible disclosureNo bounty promised unless separately stated

Report vulnerabilities in aisecurity.llc systems. Do not access, modify, destroy, or exfiltrate customer data. Do not test third-party systems or customer environments. Do not perform denial-of-service, phishing, social engineering, malware, or destructive testing. Stop after the minimum non-destructive proof needed to demonstrate the issue. No bounty is promised unless a separate program says so.

1. Plain-English Summary

  • Report vulnerabilities in aisecurity.llc systems.
  • Do not access, modify, destroy, or exfiltrate customer data.
  • Do not test third-party systems or customer environments.
  • Do not perform denial-of-service, phishing, social engineering, malware, or destructive testing.
  • Stop after the minimum non-destructive proof needed to demonstrate the issue.
  • No bounty is promised unless a separate program says so.

2. In-Scope Assets

Only aisecurity.llc-owned assets that are publicly accessible or explicitly provided to you for testing are in scope. Use only accounts, organizations, and workspaces you control unless aisecurity.llc provides separate written authorization.

  • Public website.
  • Trust center and legal routes.
  • Platform and customer portal.
  • /scope and /start flows.
  • Private offers and contract packet access.
  • Authentication and session flows.
  • Account, organization, workspace, and tenant boundaries.
  • Roles, entitlements, seats, and permissions.
  • Stripe, checkout, and entitlement provisioning logic.
  • Workbench Copilot.
  • Packet, report, and evidence rendering.
  • Uploaded artifacts and evidence files.
  • API routes and webhooks.
  • SSO, SAML, OIDC, and SCIM implementation.
  • OAuth and SaaS integrations and callbacks.
  • Browser extension.
  • Native app.
  • AI Security Workbench tools, including code scanning, adversarial testing, RAG evaluation, and artifact analysis features.
  • LMS, Academy, and Workforce Readiness access.

3. High-Value Findings

  • Authentication bypass.
  • Session weakness.
  • Insecure direct object reference (IDOR).
  • Tenant or workspace isolation failure.
  • Role or entitlement escalation.
  • Unauthorized contract or private-offer access.
  • Evidence or artifact exposure.
  • Uploaded file exposure.
  • Copilot prompt or evidence leakage.
  • OAuth token exposure.
  • SSO or SCIM provisioning flaw.
  • Stripe or seat provisioning abuse.
  • XSS or CSRF.
  • SSRF or RCE.
  • Secrets leakage.
  • Badge, attestation, or claim tampering.
  • Unauthorized report or packet access.
  • API authorization flaws.

4. Out of Scope

  • Denial-of-service or stress testing.
  • Phishing or social engineering.
  • Malware.
  • Physical attacks.
  • Credential stuffing or password spraying.
  • Spam.
  • Attacks against third-party providers.
  • Attacks against customer environments.
  • Accessing other customers' data.
  • Modifying or deleting customer data.
  • Exfiltration beyond minimal proof.
  • Automated high-volume scanning.
  • Persistence.
  • Destructive testing.
  • Bypassing payment to obtain paid services.
  • Testing cloud or SaaS provider infrastructure directly.

5. Third-Party Integrations

Do not test third-party providers directly through this program. Report provider vulnerabilities to the provider. Report vulnerabilities in aisecurity.llc integration logic, token handling, callback validation, tenant isolation, or authorization to us.

6. Safe Testing Rules

  • Use your own account or workspace.
  • Do not access other users' or customers' data.
  • Minimize proof.
  • Stop when impact is demonstrated.
  • Avoid privacy harm.
  • Avoid service disruption.
  • Do not publicly disclose before coordination.
  • Do not use findings to extort, threaten, or pressure.
  • Report promptly.

7. If You Inadvertently Access Customer Data

If a test unintentionally reveals another customer's data, another user's data, or other data you were not authorized to see:

  • Stop testing immediately and do not view, copy, store, or share more than the minimum needed to report the issue.
  • Do not modify or delete the data.
  • Report what you saw and how you accessed it in your report, including the scope of exposure if known.
  • Securely delete any copies you made once we confirm receipt of your report, unless we ask you to retain them briefly for verification.
  • Treat what you saw as confidential; do not disclose it to anyone other than aisecurity.llc.

Handling that follows this section is treated as part of good-faith research under Section 11 and does not itself take the report out of scope.

8. How to Report

Please include:

  • Affected URL or feature.
  • Steps to reproduce.
  • Impact.
  • Account or workspace used.
  • Timestamp.
  • Screenshots or video only if safe and redacted.
  • Suggested severity.
  • Contact information.
  • Whether any customer data may have been exposed.

Send reports to security@aisecurity.llc. If you need encryption, request a PGP public key before sending sensitive details.

9. Response Expectations

  • We aim to acknowledge complete, in-scope reports within three business days and provide an initial triage update when practical.
  • Remediation priority depends on severity and exploitability.
  • We may ask for clarification.
  • We may not respond to spam, low-quality automated scans, or out-of-scope reports.
  • No bounty is promised unless separately stated.

10. Severity Expectations

Suggested severity helps us triage, but we make our own severity determination based on exploitability and exposure. General handling by severity:

SeverityExampleGeneral handling
CriticalAuthentication bypass, tenant isolation failure, RCE, mass data exposure.Prioritized above other work; we may ask for a call or additional detail to confirm scope and impact quickly.
HighPrivilege escalation, IDOR affecting other customers, SSRF, secrets leakage.Prioritized remediation; acknowledgment includes a triage note on planned handling.
MediumXSS, CSRF, session weakness, limited-impact authorization flaws.Scheduled into the normal remediation backlog based on exploitability and exposure.
Low / InfoBest-practice gaps, defense-in-depth findings, missing hardening headers.Logged for future hardening; may not receive an individual remediation timeline.

These are general handling expectations, not a committed remediation SLA. A signed agreement may define stricter remediation timelines for a specific engagement.

11. Duplicate and Overlapping Reports

  • The first complete, in-scope report of a given root-cause issue is treated as the primary report.
  • Later reports of the same root cause are marked as duplicates; we may still acknowledge receipt.
  • If two reports describe the same symptom but different root causes, both may be treated as valid, separate reports.
  • Any public acknowledgement is offered at our discretion and, where offered for a duplicate, does not imply an independent finding.

12. Coordinated Disclosure

  • Do not publicly disclose a vulnerability, proof of concept, or exploit details before we have confirmed the issue is resolved or have otherwise agreed on a disclosure date.
  • Contact us before disclosing if you have a deadline (for example, a conference talk or academic publication) so we can coordinate timing.
  • We will tell you when a reported issue has been remediated where practical.
  • We may request a reasonable extension if remediation requires more time, and will explain why.
  • Coordinated disclosure applies to aisecurity.llc-owned systems only; disclosure of third-party or provider issues should follow that party's own process.

13. Good-Faith Research and Safe Harbor

We consider security research conducted consistent with this policy to be authorized, good-faith research. We will not pursue civil action or refer a matter for criminal prosecution for good-faith research that follows this policy, including In-Scope Assets, Safe Testing Rules, the handling described in Section 7 for inadvertently accessed data, and Coordinated Disclosure.

This policy does not authorize unlawful activity, access to customer data beyond what Section 7 describes, testing outside scope, service disruption, or violation of third-party terms. If you are uncertain whether a test is permitted, ask before proceeding. If a third party (including a customer or provider) initiates legal action related to research that we determine was conducted in good faith and in accordance with this policy, we will make that determination known.

Public acknowledgement may be offered at our discretion and only with the reporter's consent. No payment or bounty is promised unless a separate program expressly states otherwise.

14. Key Terms

Authorized Testing
Security testing performed only after written scope authorization and, where applicable, an accepted Assessment Terms Addendum and Rules of Engagement. Using the website, platform, or scoping forms does not by itself authorize testing of any target.
Evidence
Logs, traces, screenshots, findings, packets, reports, questionnaire materials, and other artifacts generated or collected to document a service, assessment, or governance activity.
Evidence Boundary
The agreed limit on what Evidence is collected, retained, shared, or published for a given engagement, as set by the applicable SOW, Evidence Handling Policy, Data Retention & Redaction Policy, or customer instruction.
AI Security Workbench
The hosted platform and product surface (also called the "Workbench") that provides scoping, packet generation, security analysis tools, Workbench Copilot, evidence handling, and related AI-security features to customers.

Vulnerability Disclosure Policy · aisecurity.llc · Effective June 27, 2026 · Version 1.1

← Back to Legal