Security

Effective date: July 4, 2026

Security

This Security page explains how OCO receives public security reports and what is not authorized. Public language about cybersecurity, penetration testing, DevOps, application security, AI security, or security research does not authorize testing against OCO, its clients, its ventures, its providers, or any third-party system.

OCO’s public security position is designed to encourage responsible reporting without creating broad testing permission. Even if OCO publicly offers cybersecurity or penetration testing services, that does not authorize anyone to test OCO assets, client assets, provider assets, ventures, domains, APIs, AI systems, or infrastructure without written scope.

Authorization Required

No scanning, probing, exploitation, credential testing, social engineering, denial-of-service testing, AI abuse testing, physical testing, phishing, spam, data extraction, persistence, lateral movement, or third-party testing is authorized without written scope approval from OCO and the proper system owner. If you do not have written authorization, do not test.

Written authorization should identify the target, method, time window, accounts, intensity limits, data handling rules, stop conditions, reporting path, and owner approval. If any of those elements are unclear, the activity should pause until the scope is clarified. Silence, public marketing text, or a website contact form is not authorization.

Reporting Security Issues

If you believe you found a security issue in an OCO public asset, contact info@oco.io with a concise, non-destructive report. Keep the report private. Do not publish exploit details, customer data, internal paths, credentials, screenshots containing sensitive material, or proof that could help others reproduce harm before OCO has had a reasonable opportunity to review.

A report should minimize risk while still giving OCO enough information to triage the issue. Do not keep testing to prove impact, do not access data beyond what is necessary to confirm the issue, and do not contact customers, users, vendors, employees, or third parties about the finding unless OCO explicitly coordinates that communication.

What to Include

A useful report includes the affected public URL or asset, a short description of the issue, the observed impact, minimal reproduction steps that do not cause damage, timestamps, browser or tool context, and your contact information. Do not include active exploit chains, private data dumps, credentials, automated scans at scale, or material obtained from systems you were not authorized to access.

Screenshots should be limited and redacted where possible. If a finding involves sensitive data, describe the category and proof path instead of sending the data itself. If you believe encrypted or secure transfer is needed, say so in the first message without including the sensitive material.

Out of Scope

Out-of-scope activity includes denial of service, destructive testing, persistence, malware, extortion, social engineering, physical attacks, phishing, credential stuffing, spam, data exfiltration, access to client environments, testing third-party providers, privacy violations, public disclosure before coordination, and any activity that degrades availability, integrity, confidentiality, or user trust.

Testing that creates business interruption, privacy harm, data integrity risk, account lockouts, resource exhaustion, reputational pressure, or public alarm is not acceptable through the public reporting path. OCO may treat harmful or unauthorized activity as abuse even if the actor claims a security research purpose.

Good-Faith Handling

OCO appreciates good-faith reports that avoid harm, stay within public assets, respect privacy, and follow this policy. This page is not a bug bounty, reward promise, or blanket safe harbor. It does not authorize testing, waive rights, or bind third parties. OCO will review good-faith reports based on the facts, applicable law, and whether the reporter avoided unauthorized or harmful activity.

Good faith means the reporter stops when risk becomes apparent, avoids persistence or access expansion, protects any accidentally encountered information, does not demand payment or leverage disclosure pressure, and gives OCO enough time to understand the issue. OCO may still involve providers, owners, counsel, or authorities when needed.

Response and Remediation

OCO may acknowledge, investigate, prioritize, remediate, request clarification, decline out-of-scope reports, or coordinate with affected owners or providers. Timing depends on severity, reproducibility, ownership, vendor involvement, and operational risk. Reports may be retained as security records and may not receive detailed public confirmation if doing so would expose sensitive information.

A remediation path may include temporary mitigation, configuration change, code change, access revocation, provider coordination, credential rotation, monitoring, user communication, retesting, or decision to accept residual risk. OCO may not disclose every remediation detail publicly when doing so would increase risk.

Contact

Questions about public legal, privacy, security, governance, or disclosure information can be sent to info@oco.io. Do not send credentials, private datasets, exploit details, production secrets, or confidential third-party material through public email.

Public email is a triage channel. If OCO decides that a matter requires sensitive exchange, the next step may require a separate process, verified identity, written scope, secure transfer path, or owner approval. Until that exists, public email should be treated as unsuitable for secrets, regulated data, exploit material, or confidential project files.