SecurityPolicy

1. Overview

We take the security of our customers' data seriously. This page explains the controls and processes XOVO Technologies uses to protect information across our products, services, and internal operations.

2. Data Protection

• Encryption in transit (TLS 1.2+) and at rest (AES-256).
• Least-privilege, role-based access with MFA for administrators.
• Secrets stored in managed vaults; keys rotated regularly.

3. Application Security

• Secure SDLC with peer review and automated CI checks.
• Dependency and container scanning for known CVEs.
• OWASP Top 10 controls for auth, validation, and session management.

4. Infrastructure

• Network segmentation with restricted ingress and firewalls.
• Centralized logging, alerting, and 24/7 monitoring.
• Encrypted backups and tested disaster recovery procedures.

5. Compliance

We align our controls to recognized frameworks and follow regional data protection regulations as required by customer engagements. Contact us for specific compliance documentation and DPAs.

6. Vulnerability Disclosure

If you believe you have found a security issue, please notify us at contactus@xovotechnologies.com. We will investigate promptly and appreciate responsible disclosure.

7. Incident Response

We maintain an incident response process covering triage, containment, eradication, and post-mortem review. Customers are notified without undue delay if their data is impacted, consistent with contractual and legal obligations.

8. Browser-Facing Controls

Most of this page describes controls you have to take our word for. These are the exceptions: headers this site sends on every response, which you can verify yourself with a single request.

The server also removes the header that advertises what it runs on, applies rate limiting, and serves one canonical hostname so a request cannot be quietly answered from a second origin.

9. AI-Specific Risks

An autonomous agent introduces a class of risk that a conventional application does not have, and treating it as ordinary software is the mistake most often made in this category. An agent takes actions, so a successful prompt injection is not a disclosure bug, it is an unauthorised transaction.

Systems we build are scoped accordingly. An agent gets the narrowest set of tools that lets it finish its job, actions that cost money or leave the organisation route through a human, and untrusted input is treated as data rather than instruction. Retrieval is grounded in the client’s own sources so an answer can be traced back to where it came from.

Client data is not training data. Enterprise prompts are held under a zero-retention policy and a client’s proprietary content is never used to train foundational models without explicit, opt-in consent.

10. Shared Responsibility

Where a system runs inside a client’s own environment, the boundary matters more than any single control. We are responsible for the code we write, the architecture we specify, and the handover documentation that lets the client operate it.

The client is responsible for their own identity provider, their network perimeter, who is granted access after handover, and the credentials issued to the system. We say this plainly at architecture stage rather than in an incident review, because the split decides who is watching which alert at three in the morning.