Accounts, roles and access controls
Practice membership, client-request credentials, private files and machine access.
Source reviewed Security and privacy documentation
The implementation uses several credentials for different purposes. Review which one applies to the action rather than assuming every link is a login.
| Credential | Boundary |
|---|---|
| Signed-in firm member | The practices they belong to, with role checks for privileged actions |
| Accepted client invitation | The invited client's relationship with the firm |
| Sign / Verify token | One request or check, subject to expiry and cancellation |
| Practice API key | The key's practice and granted MCP scopes |
| Short-lived file URL | Temporary access to the specific file whose URL was issued |
Practice isolation and roles
Practice membership determines which practice's records you can access. Privileged actions also require the appropriate role and permission for the target record. The UI offers Owner, Admin and Member access, as described in team roles.
Removing a colleague changes their practice membership. Review machine keys separately because those keys act as the practice. The MCP server checks scopes when a tool is called; seeing a tool listed does not grant permission to use it.
Loading diagram…
Diagram source
flowchart TB
accTitle: Practice access boundaries
accDescr: Practice-member access depends on the signed-in account, target practice and permission for the requested action. This conceptual diagram does not describe every enforcement mechanism.
U[Practice member requests an action] --> S[Check account and target practice]
S --> P{Membership and required permissions permit the action?}
P -->|Yes| A[Read or change authorised practice data]
P -->|No| X[Refuse access]
class S,P controlThis is a conceptual boundary, rather than an inventory of enforcement paths. Client invitations, request links and MCP keys have the separate limits listed above. A permitted record access does not make the associated files public.
Shared sessions and second factors
The practice products share sign-in within the same browser on
beforemay.com.au and its product subdomains. Those products belong to the same
session trust boundary. Treat a signed-in browser as access to your practice;
each colleague should use their own account. Preview domains, private windows
and different browsers do not automatically share the production session.
The source-reviewed practice-member flow requires a passkey or authenticator app, with a temporary setup grace period for eligible existing members. The product shows the setup deadline when that grace applies. A successful email or provider sign-in alone does not complete a required second-factor check. Sign-in guidance explains setup, screen locks and recovery. An assessment should confirm the deployed enforcement, grace settings and any dedicated demonstration-account exceptions separately.
Files and request links
Source documents are in private storage. Authorised flows issue short-lived signed URLs rather than storing permanent public links. A signed URL is still a bearer credential while valid: do not paste it into a public ticket or forward it to someone who should not read the file.
Signing and verification links are checked for the particular request. A replacement link invalidates the previous link. The client's Verify page exposes coarse check state rather than the firm's internal risk or screening notes.
Scope of this description
This guide describes implemented access boundaries, not a penetration-test report or a guarantee against every cross-practice defect. For assurance, request the current deployed configuration and negative-access tests listed in assessment evidence.