clmSpace
Documentation
Security & compliance

Roles & access control

People sign in with your existing Microsoft identity, and what each person can see and do is governed by their role, by the groups they belong to, and by the rules you set on individual agreements.

Single sign-on with Microsoft Entra

Your team signs in with Microsoft Entra ID, the same Microsoft work account they already use, including sign-in from within Microsoft Teams. There is no separate password for clmSpace to manage, so your existing controls (conditional access, multi-factor) continue to apply at the door.

  • Once a person is signed in, the platform issues its own short-lived session, scoped to your tenant and to that user, so every action is attributable.
  • Approved integration clients, such as the Microsoft Copilot connector, authenticate with their own credential rather than a person’s session.

Admin and verifier roles

Access follows least privilege: people get the access their role needs and nothing more. Two roles cover day-to-day work, and a separate platform-owner scope is reserved for operators rather than tenant users.

  • Admin. Manages the tenant: connections and bindings, the playbook, role assignments, and verification of AI suggestions.
  • Verifier. Reviews and confirms or overrides AI-extracted obligations in the Review queue, so AI output becomes relied upon only after a named person signs off.

Agreement-level access control

Beyond roles, you can control access agreement by agreement. Access combines two kinds of rule, and both are evaluated on every read and write:

  • Role and group permissions grant access to the people in a given role or business group, for example legal or finance, so a whole team can be admitted in one step.
  • Attribute rules match on the characteristics of the agreement and the person, so you can express conditions such as who may see a particular category of agreement.
Restricted agreements are private by default
When you mark an agreement restricted, it is invisible to everyone until you grant access. There is no access without an explicit grant, the platform does not reveal that a restricted agreement exists to people who lack a grant, and access is checked the same way whether someone opens a list or a single record. Every check fails closed, so an uncertain decision denies rather than admits.

Auditability and operator support

  • Every grant is audited. When access is granted or changed, the platform records who made the change and when, so you can answer who could see what at any point in time.
  • Operator bypass for support. The platform-owner scope lets Rated Counsel operators assist with support and incident response. This access runs through per-tenant audit records and explicit, time-boxed grants, so it is visible and accountable to you.
Covered by automated tests
Authentication, authorization, tenant isolation and agreement-level access control are exercised by an automated test suite of more than 160 tests, so these controls are verified on every change rather than trusted by assertion.

Related