Identity and Access
The platform uses separate access boundaries for different audiences. One kind of access does not automatically grant another.
| Audience | Typical access | Primary boundary |
|---|---|---|
| Internal team | Sales and operations workspace | Named account, active session, role and capability |
| Customer contact | Customer reporting or project portal | Provisioned contact and organization scope |
| Private recipient | Approved proposal, brief, or review | Expiring or revocable recipient access |
| Public participant | Content, claim, registration, or offer | Workflow-specific rules and consent |
| Service integration | Approved machine-to-machine task | Scoped, revocable service access |
Customer isolation
Section titled “Customer isolation”Customer portal identities are tied to one customer organization. Customer-facing queries are scoped to that organization; an internal session and a customer session are not interchangeable.
Administrative access
Section titled “Administrative access”Administrative actions require both a valid internal identity and the capability for the requested action. Higher-risk actions are separated from routine operations. Authorization errors deny the action rather than broadening access.
Private recipient links
Section titled “Private recipient links”Private links are designed for a specific approved path and may expire, be revoked, or bind to an initial visit. They are not general accounts and should be treated as confidential.
Lifecycle expectations
Section titled “Lifecycle expectations”- Provision only people who need access.
- Use named identities rather than shared credentials.
- Review roles when responsibilities change.
- Disable access promptly during offboarding.
- Do not forward private links or sign-in messages.
- Report suspected misuse so access can be revoked and reviewed.
Exact session, token, route, and credential implementation details are reserved for confidential security review.