Access Control Policy

1. Purpose

This policy governs how access to Lever AI's systems and data is granted, used, reviewed, and revoked. The Information Security Policy states the company's access-control position in summary (section 3.4 of that policy); this policy is the authoritative expansion of that ground, and where the two differ on a point of access control, this policy prevails. It is informed by ISO/IEC 27001:2022 Annex A and the SOC 2 Trust Services Criteria.

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 every system through which company or customer data can be reached: the Microsoft Azure subscriptions and the resources within them (the application services, the managed database, blob storage, and the container platform); the company's GitHub organisation and its private repositories; the data stores, including the restricted auth store that holds customer tenant credentials; deployment mechanisms; the agent service and its administrator-facing interface; and the connectivity into customer environments. The standards for the credentials themselves — passwords, multi-factor authentication, and the prohibition on shared accounts — are set by the Password Policy, which this policy invokes rather than restates.

3. Policy

3.1 Principles

Access is granted on the principle of least privilege: the minimum access needed for the work, and nothing by default. Every grant of access is tied to a named individual through an individual account, so that any action taken can be attributed to the person who took it; shared accounts are prohibited except for the sealed break-glass credentials described in section 3.7. Access that is no longer needed is removed, not left in place.

3.2 Granting access

Access is granted only against a business need, by the Founder or by a designated engineer authorised to grant it. Each grant is recorded: what was granted, to whom, at what scope, by whom, and when. Grants use the narrowest role or scope that serves the need; administrative and owner-level roles are granted only where the work genuinely requires them. Where team size allows, no one approves their own access; where the size of the team makes that separation impractical, the self-granted access is recorded like any other and is explicitly confirmed at the next quarterly review — the record and the review are the compensating controls. Access for a contractor or third party is sponsored by the Founder, limited to the engagement's need, and time-bound.

3.3 Authentication

All access is through individual, named accounts. Multi-factor authentication is required on all production, cloud, and source-control accounts, as mandated by the Password Policy, and credential strength, uniqueness, and handling follow that policy in full.

3.4 Production access and the access inventory

Production access means any access that can read or modify customer data or change what runs in production: roles on the cloud subscriptions, membership of the source-control organisation, access to the data stores and the restricted auth store, deployment credentials, and the encrypted tunnels into customer environments. Production access is the exception, not the default, and is held only by those whose role requires it. Production systems, the cloud consoles, and the credentials that open them must be accessed only from devices enrolled in the company's device management (MDM) tooling: enrolment is a precondition of production access, and a device outside management is not an accepted path to production, whoever is holding it.

The Security Owner maintains an inventory of production access: every account, key, and credential with such access, who holds it, its scope, and when it was granted. The inventory is updated whenever access is granted or revoked, and it is the working input to the quarterly review in section 3.5 — a review is only as good as the completeness of this list, so keeping it current is a standing duty, not a periodic one.

3.5 Access review

Access to cloud, source-control, and data-store systems is reviewed quarterly. The review confirms, for each entry in the access inventory, that the access is still needed at its current scope; access that is excessive, dormant, or no longer justified is removed. The review also confirms that multi-factor authentication is enforced on the accounts that require it under the Password Policy, and that the work devices in use are enrolled in the device management (MDM) tooling and meet the requirements of the Physical Security Policy — each holder of production access affirming at the review that their devices remain compliant, including that they are full-disk encrypted. Central attestation of disk encryption through the MDM is a roadmap control; until it is in place, this affirmation at the quarterly review is how full-disk-encryption compliance is established. The review is recorded with the reviewer, the date, and the changes made, and the inventory is corrected to match.

3.6 Revocation

When someone leaves the company or changes role, their access is revoked or re-scoped within 24 hours, as part of the leaver and mover checklist in the Personnel Security Policy. When a customer withdraws or rotates a tenant credential it has provisioned, the withdrawal takes effect immediately. Where an account or credential is suspected of compromise, it is suspended at once and the matter is handled under the Incident Response and Business Continuity Policy. Where a device used for production access falls out of compliance with the managed baseline — its enrolment lapses, its patching falls behind, or a required control is found disabled — the access exercised from that device must be reviewed, and it may be suspended or revoked until the device is restored to compliance.

3.7 Break-glass access

Break-glass credentials exist for genuine emergencies in which the normal access path is unavailable and waiting would worsen the harm — typically during incident response. They are stored sealed, as required by the Password Policy. Using them requires the Founder's authorisation, or, where that is not immediately possible, the Founder is notified without delay. Every use is logged with who, when, and why; the credential is rotated after use; and each use is reviewed afterwards to establish whether the normal access model needs to change.

3.8 Tenant isolation and customer-side access

Every conversation and agent session is bound to an owner identity — the customer tenant domain and the administrator using it — and any attempt to reach another owner's data or sessions is refused server-side, as summarised in section 3.4 of the Information Security Policy. These isolation controls are security-critical: any change affecting them is treated as a security-relevant change under the Change Management Policy. On the customer side, the service operates only through tenant-scoped credentials the customer provisions, which confer no more access than the customer has granted; roles and permissions inside the customer's HR platform remain under the customer's control, and the service configures them only at the customer's direction.

4. Responsibilities

The Founder is accountable for this policy and approves exceptions to it. The Security Owner operates it day to day: maintaining the production-access inventory, running the quarterly reviews, and ensuring revocations happen within the required time, as assigned in the Security Roles and Responsibilities document. Designated engineers grant access only within their authority and record every grant. Every member of staff uses only the access they have been granted, never shares an account or credential, and reports access that looks wrong — their own included.

5. Exceptions

Any exception to this policy must be requested in writing, assessed for risk, approved by the Founder, time-bound, and recorded. Open exceptions are revisited at each quarterly access review.

6. Review

This policy is reviewed at least annually and whenever there is a significant change to the company's systems, team, or the engagement. The document owner maintains its version history.