PlatformIdentity, RBAC, audit
AccessArc — the identity layer underneath.
The identity, access control, and audit layer that underpins TeamSync — what makes permissions-aware AI a property of the architecture, not a per-deployment policy.
What AccessArc provides.
Eight functions, all of them enforced beneath every capability on the platform. Talk to a security solutions engineer.
| Function | Detail |
|---|---|
| Identity federation | SAML / OIDC / SCIM with Microsoft Entra ID, Okta, Ping Identity, ForgeRock, OneLogin, customer-managed IdPs. HSPD-12 / FIPS 201 / PIV for federal. |
| RBAC + ABAC enforcement | Permissions evaluated per request, not per session; AI copilot inherits user scope. |
| Per-tenant envelope encryption | Per-tenant master key (KEK) wrapping per-class data-encryption keys (DEK); crypto-shred via DEK destruction. See Crypto-shred pillar. |
| Customer-controlled key custody | Where sovereignty is required, customer-controlled HSM-backed key custody. |
| Tamper-evident audit ledger | Merkle hash chain on every event; per-day root cross-attested across regions and witness nodes. See Tamper-evident audit pillar. |
| Tenancy isolation | Multi-tenant with hard isolation; multi-region tenancy supported per residency requirement. |
| Backup + DR | Per-tenant backup + DR with audit-trail continuity preserved across recovery. |
| MFA + session controls | Configurable MFA; session lock per regulator (e.g., CJIS 30-min). |
The AI platform inherits AccessArc's identity model. That is what makes the answer to “can the AI return content the user is not authorised to see” the architectural answer “no” — not the policy answer “we ask it not to.”
Four properties AccessArc makes possible.
| Property | How AccessArc enables it |
|---|---|
| Permissions-aware AI | Per-request RBAC + ABAC scoping the retrieval set |
| Crypto-shred for individual rights | Per-data-subject envelope encryption |
| Cryptographic audit on AI activity | Merkle ledger anchoring every AI request + response |
| Cross-region attestation | Per-day roots cross-signed across regions |
How AccessArc is provisioned.
Programmatic where it should be, customer-defined where it has to be.
| Provisioning step | Mechanism |
|---|---|
| Tenant creation | Programmatic via API; admin via console |
| User + group sync | SCIM with the customer's IdP; just-in-time provisioning supported |
| Role + attribute model | Customer-defined; AccessArc enforces |
| Key custody | TeamSync-managed by default; customer-managed HSM optional |
| Region selection | Per-tenant or per-class |
Identity review
Bring your IdP and your regulator.
A security solutions engineer maps your identity model, residency requirements, and key custody posture onto AccessArc — and tells you where the gaps are.