Cryptography and Encryption Policy

1. Purpose

This policy defines the cryptographic protections Lever AI requires for the data it processes and the systems it operates, the algorithms and protocols that may be used, and how the keys behind them are held and managed. The Information Security Policy summarises these protections; this policy is the authoritative statement of the company's cryptographic requirements. It is informed by ISO/IEC 27001:2022 Annex A and current industry guidance, including NIST recommendations on algorithm and key strength.

2. Scope

This policy applies to all Lever AI personnel and to any contractor or third party acting on the company's behalf. It covers all data the company creates, processes, stores, or transmits in delivering its service, and every system it operates to do so — including the agent service and MCP tool server on Microsoft Azure, the managed data stores behind them, the customer-hosted execution component where deployed, and the connectivity into customer platform environments. Which data must be encrypted, and to what standard of handling, follows the classes defined in the Data Classification Policy; Restricted data, including customer data and credentials, must always be encrypted in transit and at rest.

3. Policy

3.1 Encryption in transit

All data in transit over public or untrusted networks must be encrypted using TLS 1.2 or above, with TLS 1.3 preferred wherever the endpoint supports it. This applies to every external endpoint the company exposes, to traffic from the agent service to its managed database, to calls to the AI provider's API, and to all traffic to the target HR platform's REST APIs. Connectivity into customer platform environments runs over encrypted tunnels (SSH carried over TLS on port 443), arranged with the customer. The same standards apply to the customer-hosted execution component running inside a customer's infrastructure. Plaintext protocols must not be used to carry customer data, credentials, or any Restricted or Confidential information.

3.2 Encryption at rest

Data at rest in the company's production data stores is encrypted with AES-256 through Azure service-side encryption. This covers Azure Cosmos DB for MongoDB (conversations, job state, transcripts, and telemetry), Azure Blob Storage (attachments), and App Service persistent storage (per-conversation working files). Any new production data store must provide at-rest encryption of at least this standard before it is adopted.

3.3 Application-layer cryptography

API authentication tokens for the target HR platform are RSA-encrypted in accordance with the platform's secured-identity scheme, as designed for the engagement. Service credentials are held in restricted stores and are never embedded in source code, committed to repositories, or written to logs, as required by the Password Policy. Where a Lever AI system stores a password verifier of its own, it must use an approved password-hashing scheme from the table in section 3.4 with a per-credential salt; passwords must never be stored reversibly or in plain hash form.

3.4 Approved algorithms

Only the algorithms and protocols below may be used for security purposes. Anything not listed requires a recorded exception under section 5 before use.

3.5 Prohibited practices

The following are prohibited without exception:

• Designing, implementing, or deploying custom or home-grown cryptographic algorithms, protocols, or modes. Only established, publicly reviewed cryptography, through well-maintained libraries or platform services, may be used — ever.
• Disabling or weakening certificate validation, hostname verification, or protocol-version checks in any environment that handles customer data.
• Hard-coding keys, certificates, or other cryptographic secrets in source code, configuration committed to source control, or container images.
• Continuing to use an algorithm or key length after it has been moved to the "not permitted" column of this policy, beyond an agreed, time-bound migration recorded as an exception.

3.6 Key management and custody

Encryption keys for data at rest in the company's Azure data stores are Microsoft-managed platform keys: Microsoft generates, stores, rotates, and protects them within Azure's key management infrastructure, and Lever AI relies on Microsoft's published, independently audited controls for their protection. Lever AI operates no hardware security modules or key-management infrastructure of its own, and states this plainly. Customer-managed keys (CMK) for the Azure data stores are not in place today; offering CMK on customer request is a committed item on the company's security roadmap. Application-level secrets and credentials — service credentials, platform tokens, and TLS material where handled directly — are held in access-restricted stores under the least-privilege rules of the Access Control Policy, and are rotated on suspicion of compromise, on personnel departure, and when a customer withdraws or replaces a credential.

3.7 Certificates

TLS certificates on the company's public endpoints are provisioned and renewed through Azure-managed TLS. Any certificate managed directly by the company must be issued by a recognised certificate authority, tracked to its expiry date, and renewed before expiry; self-signed certificates are not used on production endpoints that carry customer data.

4. Responsibilities

The Security Owner owns this policy, approves any change to the approved-algorithms table, and assesses exception requests. The Engineering owner is responsible for implementing these standards in the product and infrastructure, keeping cryptographic libraries current under the Vulnerability Management Policy, and migrating away from deprecated algorithms. All personnel are responsible for using only approved cryptography and for reporting any suspected weakness or key compromise without delay under the Incident Response and Business Continuity Policy.

5. Exceptions

Any exception to this policy must be requested in writing, assessed for risk by the Security Owner, approved by the Founder, limited in time, and recorded with its scope and compensating controls. Exceptions are reviewed at each policy review and lapse at their end date unless re-approved. No exception may authorise custom cryptography.

6. Review

This policy is reviewed at least annually and whenever there is a significant change — including publication of a practical attack against an approved algorithm, a change in platform or provider cryptographic capability, or a customer requirement that alters key custody. The document owner maintains its version history.