The security of our platform, our customers' data, and the integrity of our AI systems is our highest priority. We recognize that independent security researchers play a critical role in maintaining this security. This Responsible Disclosure Policy establishes a framework for security researchers to report vulnerabilities to Otonomii in a safe, structured, and mutually beneficial manner.
We are committed to working with the security community to identify and remediate vulnerabilities promptly. We will not pursue legal action against researchers who discover and report vulnerabilities in good faith and in accordance with this policy.
01
Scope
This policy covers all internet-facing systems, applications, APIs, and websites owned and operated by Otonomii. This includes:
--Production web applications at otonomii.com and all subdomains
--Public-facing APIs and API documentation portals
--Authentication and authorization systems
--Customer-facing dashboards and management consoles
--Mobile applications published by Otonomii
--Open-source projects maintained by Otonomii on public repositories
Excluded: Third-party systems, services, and platforms not owned or operated by Otonomii, even if they integrate with Otonomii services. If you are unsure whether a system is in scope, contact security@otonomii.com before testing.
02
Covered Vulnerabilities
The following vulnerability classes are within the scope of this disclosure policy. This list is not exhaustive — if you discover a vulnerability that does not fit neatly into these categories but poses genuine security risk, please report it.
A
Misconfigurations
Incorrectly configured servers, cloud storage buckets, access controls, or security headers that expose data or functionality beyond intended scope. Includes default credentials, overly permissive CORS policies, and debug interfaces exposed to production.
B
Cross-Site Request Forgery (CSRF)
Attacks that force authenticated users to execute unintended actions on a web application. Includes state-changing operations performed without proper anti-CSRF tokens or SameSite cookie protections.
C
Privilege Escalation
Vulnerabilities allowing a user to gain elevated access beyond their authorized permissions. Includes both vertical escalation (user to admin) and horizontal escalation (accessing another user's resources).
D
SQL Injection
Insertion of malicious SQL statements through application inputs that can read, modify, or delete database contents. Includes blind SQL injection, second-order injection, and out-of-band data exfiltration.
E
Cross-Site Scripting (XSS)
Injection of malicious scripts into web pages viewed by other users. Includes stored XSS (persistent), reflected XSS (non-persistent), and DOM-based XSS. Reports must demonstrate impact beyond self-XSS.
F
Directory Traversal
Exploitation of insufficient input validation to access files and directories outside the intended scope. Includes path traversal via dot-dot-slash sequences, null byte injection, and URL encoding bypasses.
G
Authentication Bypass
Circumvention of authentication mechanisms to gain unauthorized access. Includes broken authentication flows, session fixation, token forgery, and multi-factor authentication bypasses.
H
Remote Code Execution (RCE)
Vulnerabilities allowing execution of arbitrary code on Otonomii servers or infrastructure. Includes command injection, deserialization attacks, server-side template injection, and code injection through file uploads.
I
Server-Side Request Forgery (SSRF)
Exploitation of server functionality to make requests to unintended internal or external resources. Includes blind SSRF, partial SSRF, and SSRF through URL parsers or redirect chains.
03
Excluded from Scope
The following are explicitly excluded from this disclosure program. Reports for these items will be acknowledged but will not be processed as vulnerability disclosures.
01
General best practices without proof of concept
Reports that identify theoretical weaknesses or suggest security improvements without demonstrating a concrete, exploitable vulnerability. We value constructive feedback but require evidence of actual risk for disclosure processing.
02
Physical compromise of facilities or devices
Attacks requiring physical access to Otonomii offices, data centers, or employee devices. Physical security is managed separately and is not within the scope of this disclosure program.
03
Rate limiting on non-authentication endpoints
Absence of rate limiting on endpoints that do not handle authentication, authorization, or sensitive data operations. Rate limiting on login, password reset, and API key generation endpoints IS in scope.
04
Insider compromise scenarios
Attack scenarios that assume a malicious Otonomii employee with privileged access. While we maintain robust insider threat programs, these scenarios are not addressable through external vulnerability disclosure.
05
Social engineering of Otonomii employees
Phishing, vishing, pretexting, or other social engineering attacks targeting Otonomii staff. Do not attempt to socially engineer, manipulate, or deceive Otonomii employees, contractors, or partners.
06
Reflected file download attacks
Attacks exploiting content-disposition headers to trick users into downloading malicious files. These typically require significant user interaction and are mitigated through browser security controls.
07
Account takeover via credential stuffing
Using leaked credentials from other services to access Otonomii accounts. While we monitor for credential stuffing, this is a user-side credential hygiene issue rather than an Otonomii platform vulnerability.
08
Red-teaming or adversarial model testing
Attempts to make AI models produce harmful, biased, or policy-violating outputs through adversarial prompts. These should be reported through our separate AI Safety program at safety@otonomii.com.
09
Content issues with prompts or outputs
Reports about the quality, accuracy, or appropriateness of AI model responses. Content quality is managed by the product and safety teams. Security-relevant content issues (e.g., PII leakage) remain in scope.
10
Denial of Service (DoS) attacks
Attacks intended to make services unavailable through resource exhaustion, whether volumetric, protocol-based, or application-layer. Do not test for DoS vulnerabilities as this impacts service availability for all customers.
11
Clickjacking on non-sensitive pages
Framing attacks on pages that do not contain sensitive functionality or data. Clickjacking on pages with state-changing actions (account settings, payment forms) IS in scope.
12
Missing cookie flags on non-sensitive cookies
Absence of Secure, HttpOnly, or SameSite flags on cookies that do not contain session tokens, authentication data, or sensitive information. Missing flags on session or authentication cookies IS in scope.
13
Dependency hijacking without demonstrated impact
Theoretical supply chain attacks where a dependency could be hijacked but no actual exploitation path to Otonomii systems is demonstrated. Reports must show a credible path to impact.
14
Zero-day vulnerabilities without available patches
Vulnerabilities in third-party software where the vendor has not yet released a patch and fewer than 30 days have elapsed since responsible disclosure to the vendor. We will track these internally but cannot act until patches are available.
04
AI Safety Issues
Issues related to AI model behavior, safety guardrails, harmful outputs, bias, or adversarial manipulation of AI systems should be reported separately to safety@otonomii.com. The AI Safety team operates independently from the Security team and has specialized processes for evaluating, triaging, and remediating model-level vulnerabilities. Safety reports are subject to a separate evaluation framework that accounts for the probabilistic nature of AI system behavior.
If you are unsure whether an issue is a security vulnerability or a safety concern, report it to security@otonomii.com and we will route it to the appropriate team.
05
Submission Requirements
Submit vulnerability reports to security@otonomii.com. Use PGP encryption if available (our public key is published at otonomii.com/.well-known/security.txt). Include the following information in your report:
01
Vulnerability Type and Severity
Classify the vulnerability using CWE identifiers where possible. Estimate severity using CVSS v3.1 scoring. If you are unsure about classification, provide your best assessment — we will validate and adjust during triage.
02
Technical Details
Describe the vulnerability in sufficient technical detail for our security team to understand the root cause. Include the affected component, protocol, or API endpoint. Reference relevant standards or CVEs if applicable.
03
Summary
A concise, plain-language description of the vulnerability and its potential impact. This should be understandable by a non-technical stakeholder. One to three sentences.
04
Reproduction Steps
Step-by-step instructions to reproduce the vulnerability. Assume the reader has technical competence but no prior knowledge of the specific issue. Include any prerequisites, tools required, and expected versus actual behavior at each step.
05
URL or Location
The specific URL, API endpoint, IP address, or system component where the vulnerability exists. Include the full path, query parameters, and any relevant headers. For API vulnerabilities, include the full request/response.
06
Proof of Concept
Working proof of concept demonstrating the vulnerability. This may include scripts, screenshots, HTTP request/response pairs, or video recordings. PoC should be minimal — demonstrate the vulnerability without causing additional impact.
07
Potential Impact
Describe the worst-case scenario if this vulnerability were exploited by a malicious actor. Consider data exposure, service disruption, privilege escalation, and downstream effects on customers.
08
Recommended Remediation
If you have suggestions for how to fix the vulnerability, include them. This is optional but appreciated. Our engineering team will determine the final remediation approach.
How to Write a Good Report
The best vulnerability reports are clear, concise, and reproducible. Start with a one-sentence summary that captures the essence of the vulnerability. Provide reproduction steps that a security engineer can follow without additional context. Include the actual observed behavior and the expected correct behavior. Attach evidence (screenshots, HTTP logs, scripts) rather than only describing it. If the vulnerability has preconditions (specific account type, feature flag, timing), state them explicitly. A report we can reproduce in under 30 minutes will be triaged faster than one that requires back-and-forth clarification.
06
Good Faith Requirements
To qualify for safe harbor protections under this policy, researchers must adhere to the following good faith requirements:
[01]
Test only on systems you own or have explicit permission to test. Use your own accounts for testing.
[02]
Avoid causing harm to Otonomii, our customers, or our users. Do not degrade service performance or availability.
[03]
Limit exploitation to the minimum necessary to demonstrate the vulnerability. Stop testing once you have sufficient evidence.
[04]
Do not exfiltrate, download, copy, or store customer data, user data, or any data that does not belong to you.
[05]
Do not disclose the vulnerability publicly or to any third party without prior written approval from Otonomii.
[06]
Do not attempt to access, modify, or delete data belonging to other users or customers.
[07]
Do not use social engineering, phishing, or physical attacks against Otonomii employees, contractors, or partners.
[08]
Do not demand payment, compensation, or bounties as a condition for reporting or withholding disclosure.
[09]
Confirm that you are not on any OFAC, EU, or other applicable sanctions lists.
[10]
Comply with all applicable laws and regulations in your jurisdiction.
[11]
Do not use automated scanning tools against production systems without prior coordination with our security team.
[12]
Delete all Otonomii data, artifacts, and credentials obtained during testing within 7 days of report submission.
[13]
Report vulnerabilities promptly — do not stockpile findings for later disclosure.
07
Otonomii's Commitments
Acknowledgment
We will acknowledge receipt of your report within 3 business days. The acknowledgment will include a tracking identifier for future correspondence and the name of the assigned security analyst.
Validation
Our security team will validate the reported vulnerability, confirm its severity, and determine the affected scope. We will communicate our assessment to you, including whether we agree with your severity rating and any additional context about impact.
Remediation
We will remediate confirmed vulnerabilities promptly. Critical and high-severity issues are targeted for resolution within 7 days. Medium-severity issues within 30 days. Low-severity issues within 90 days. We will notify you when the fix is deployed and invite you to verify the remediation.
Safe Harbor
We will not pursue legal action against researchers who discover and report vulnerabilities in good faith and in accordance with this policy. This commitment extends to civil claims, criminal referrals, and cooperation with law enforcement requests related to your research activities.
Attribution
With your permission, we will publicly acknowledge your contribution in our security acknowledgments page. We respect your preference for anonymity — tell us how (or whether) you would like to be credited.
08
Safe Harbor
When conducting vulnerability research in accordance with this policy, we consider your research to be authorized and we will not initiate or support legal action against you for accidental, good-faith violations of this policy. We will not pursue civil claims or initiate criminal complaints against you for circumventing technological measures where your actions are consistent with the scope of this policy.
If legal action is initiated by a third party against you for activities conducted in compliance with this policy, we will take steps to make it known that your actions were conducted in accordance with this policy and were authorized by Otonomii.
This safe harbor is contingent on good faith effort. Research that causes material harm to Otonomii, its customers, or its users — even if technically within the scope of this policy — may not be protected. When in doubt, contact us before testing.
09
Contact
Security Vulnerabilities
security@otonomii.com
PGP key: otonomii.com/.well-known/security.txt
AI Safety Concerns
safety@otonomii.com
For model behavior, bias, and guardrail issues
