Security operations#
How Lens Agents is run, protected, and supported as a platform — internal access controls, incident response, key management, backups, and the operational commitments that back enterprise deployments.
Lens Agents runs in your cluster, so most of what this page covers is operated by you, not by us. Support tiers and the commitments that go with them are agreed during the evaluation engagement.
Who operates what#
The platform installs into your cluster. That settles most operational questions in your favour, and it puts the corresponding work on your side.
| Concern | Who owns it |
|---|---|
| Infrastructure ownership | You |
| Data residency | Your cloud, your region, your VPC — see Data sovereignty |
| Operator access to customer data | Zero. The platform runs entirely within your environment; we have no path into it |
| Encryption-key management | You. encryption.key is a value you generate and hold |
| Backup and disaster recovery | Your backup and DR policy, on your database |
| Monitoring, uptime, and incident response | Your ops team operates it; we support per the agreement |
| Change management | You control upgrade cadence — see the release notes |
| Compliance scope | Your deployment falls under your own compliance program. Platform components are attested independently — see Compliance |
What we document publicly#
The following are covered in the public documentation in detail — follow the links:
- Threat model — what Lens Agents protects against, what it does not
- Sandbox isolation — kernel-enforced isolation for every agent action
- Credential isolation — server-side injection, ephemeral CA, zero credentials in agent process
- Audit trail — what is recorded, across which surfaces, with what schema
- Identity and authentication — user and agent identity models, token handling
- Policy engine — authorization semantics for every agent action
- Compliance posture — certifications, audit scope, regulatory readiness
- Data sovereignty — where data resides and exactly what leaves your cluster
- Privacy controls — PII detection and masking, domain controls, credential isolation
What we share during evaluation#
The following are available on request, typically under NDA, as part of an evaluation engagement:
- SOC 2 Type 1 attestation letter for Lens (K8S IDE), the product Lens Agents inherits controls from; Lens Agents-specific audit timeline shared on request. SOC 2 Type 2 audit covering Lens is under way.
- ISO 27001 certificate (Mirantis Inc., corporate level) and scope statement.
- Third-party penetration test reports (annual engagement).
- Vulnerability disclosure history and published CVEs.
- Incident response runbook summary — detection, escalation, customer-notification timelines, and post-incident review practices.
- Internal access controls — role separation at Lens Agents, audited operator access paths, and customer-data boundaries.
- Encryption-key management details — algorithms and rotation guidance for the keys you hold.
- Backup and disaster-recovery guidance — recovery objectives, failover, and restoration testing for an install you operate.
- Support commitments — response times by support tier.
- Data-processing addendum (DPA) and sub-processor list.
- Data retention and deletion policies per data type, including GDPR data-subject request handling.
- Business continuity plan summary.
Much of this material is organization-specific — a hardened on-premises install and a cloud-hosted one have different threat surfaces, and support tiers differ. We prefer to discuss specifics with context on your environment rather than publish a one-size-fits-all answer that will not match your actual deployment.
How to request specifics#
During an evaluation engagement, your Lens Agents account team is your point of contact for any of the above. Contact us to start an evaluation.
For security disclosures or vulnerability reports outside an active engagement, email security@lenshq.io.
Related#
- Security whitepaper — the full architectural detail this page links out to
- Compliance — certification and audit scope
- Data sovereignty — deployment-specific data residency