Security

Our security
posture.

Last updated: 4 May 2026 · Subject to change as the Service evolves

This page describes the security controls and practices Subsense OÜ (“LensHub”) implements in connection with the LensHub product (the “Service”). It is provided for transparency and to help customers conduct due diligence. Nothing on this page constitutes a warranty, guarantee, or contractual commitment. Specific contractual security commitments apply only where expressly agreed in a signed order form, the Data Processing Agreement, or other written instrument. Controls described here may evolve over time, including without prior notice, provided they continue to provide a substantially equivalent level of protection.

No system can be made completely secure. While we work to follow industry-standard practices, we do not guarantee that the Service or the data it processes will never be subject to unauthorised access, disclosure, alteration, or destruction.

Encryption

  • At rest: we implement encryption of customer data at rest using industry-standard algorithms (currently AES-256 family) on storage volumes provided by our cloud infrastructure or, for self-hosted deployments, by the customer's storage layer (for example, LUKS-encrypted volumes).
  • In transit: connections to the Service are protected with TLS (currently TLS 1.2 or higher) using strong cipher suites, with TLS 1.3 preferred where supported by clients.
  • Internal traffic: in the managed offering, internal service-to-service traffic is protected by mutual TLS or equivalent network controls. In self-hosted deployments, the customer is responsible for the network security of internal traffic.
  • BYOK (Enterprise): bring-your-own-key encryption may be available for Enterprise customers under a signed order form.

Authentication & access

  • API access uses signed tokens (JWT) with short rotation intervals.
  • Source-system connectors use the minimum scopes necessary, typically read-only, and store credentials in encrypted secret stores.
  • Administrative access to the managed Service follows the principle of least privilege and is reviewed periodically.
  • Multi-factor authentication is required for all LensHub personnel accessing production systems.

Permissions: how we work to prevent leakage

Permissions are enforced at multiple layers:

  1. ACL mirroring — when LensHub syncs a source, it ingests the available permission metadata alongside the content (for example, page restrictions, channel membership, repo collaborators, sharing scopes) and stores it as part of the context graph.
  2. Query-time enforcement — every retrieval carries the requesting user's identity. LensHub resolves the user's effective permissions across connected sources and filters results before they leave the database.
  3. Audit logging — retrieval activity is logged with user, agent, query, returned context IDs, and timestamps. Logs are exportable for customer review and SIEM integration.
  4. Reconciliation — ACL changes in source systems are reflected in LensHub on a continuous basis. The exact propagation latency varies by source-system API capabilities.

The completeness and accuracy of these controls depend on the customer's configuration, the source systems' permission models, and the timeliness of source-system API responses. Customers are responsible for the security of their source systems and for accurate, current ACL configuration.

Operational security

  • Self-hosted: customer data does not leave the customer's infrastructure. The customer is responsible for the physical, network, and operating-system security of the deployment environment.
  • Managed: no LensHub employee has standing access to customer data. Production access requires just-in-time approval with two-person sign-off, fully audited.
  • Compliance posture: Signed Data Processing Agreements (DPAs) are available for GDPR / CCPA compliance.
  • Subprocessors: LensHub uses a curated set of subprocessors. The current list is available on request and as an exhibit to a signed DPA.

Data lifecycle

Customers may export Customer Data via the standard export tooling at any time. After cancellation, customer data is purged from production systems within thirty (30) days, with backups expiring per the documented retention schedule. A confirmation of deletion is available on request.

Vulnerability disclosure & safe harbour

If you believe you have found a security vulnerability in the Service, please report it to security@lenshub.ai. We aim to acknowledge reports within 24 hours and triage within 72 hours.

If you act in good faith, in accordance with our coordinated-disclosure expectations below, we will not pursue legal action or report you for the activity. Coordinated-disclosure expectations:

  • Limit testing to systems you own or are explicitly authorised to test; do not target other customers' data.
  • Avoid privacy violations, destruction of data, and interruption or degradation of the Service.
  • Do not perform automated scanning that generates significant traffic without prior coordination.
  • Do not disclose the vulnerability publicly until we have had a reasonable opportunity to remediate (typically 90 days).
  • Do not extort, threaten, or attempt to monetise the disclosure.

We do not currently operate a paid bug-bounty programme but we acknowledge contributors on request.

Reporting an incident

To report a suspected ongoing security incident, email security@lenshub.ai with as much detail as possible. For incidents affecting customer accounts, we will follow the breach-notification timelines set out in the DPA.

Limitations

The information on this page is current as of the “Last updated” date and may change as the Service evolves. It does not create any rights enforceable against LensHub except to the extent expressly incorporated into a signed contract.