Trust & security policies

Security we practise, not just preach.

A security product has to hold itself to a higher standard than its customers. These are the policies that govern how we build Robo8 and how it behaves in your environment. They map directly to controls already in the product.

This page is a customer-facing summary template. Adapt the specifics (retention windows, contacts, jurisdictions) to your organization and have it reviewed by legal/compliance before publishing.

1. Information Security Policy

Least-privilege access enforced through role-based access control (viewer / analyst / responder / admin).
All credentials are stored only as salted hashes; secrets are injected at runtime via the Docker/Kubernetes secret convention and never committed to source or images.
Encryption in transit via TLS; security headers (HSTS, CSP, nosniff, frame-deny) on every response.
Abuse controls: per-client rate limiting and automatic lockout after repeated failed authentication.

2. Data Protection & Privacy

Local-first option: detection, reasoning, and storage can run entirely on your infrastructure — telemetry need never leave your network.
Data minimization: Robo8 processes the security signals required for detection and triage, nothing more.
Configurable retention for audit, feedback, and incident data; you control the storage backend (local files or your own database).
Where a cloud LLM is opted into, only the incident metadata needed for triage is sent, and that choice is explicit and per-deployment.

3. Acceptable Use

Robo8 is for authorized defensive use only — monitoring and protecting systems and data you own or are permitted to defend.
It performs no offensive action and must not be used for unauthorized access, surveillance, or attack.
Automated enforcement actions are bounded by an operator-set ceiling and default to dry-run.

4. AI / Model Governance

Human-in-the-loop: destructive actions always require an authenticated human approval; the model may escalate a detection but can never silently suppress one.
Explainability: every automated verdict records its technique mapping, confidence, evidence, and reasoning.
Poisoning resistance: training data is admitted only through multi-analyst consensus; low-trust contributors are automatically excluded.
Drift monitoring: model performance and input distribution are tracked continuously, with retraining triggered on significant drift.

5. Audit & Accountability

Append-only audit trail of every verdict, action, approval, and retrain.
Approvals are bound to the authenticated identity that made them — never to a self-reported name.
Operational metrics exposed via Prometheus for monitoring and alerting.

6. Incident Response

Defined severity tiers and response procedures; security incidents affecting customers are communicated promptly. (Define your own notification SLA here.)
Post-incident reviews feed back into detections and runbooks.

7. Coordinated Vulnerability Disclosure

We welcome reports from security researchers. Please report suspected vulnerabilities to [security@your-domain] (PGP: [key]). We commit to acknowledge within [X business days], work with you on a fix, and credit you on disclosure if you wish. Please act in good faith, avoid privacy violations and service disruption, and give us reasonable time to remediate before public disclosure.