Security & Compliance

Security and PDPA compliance are foundational to the Smart Document Assistant, not afterthoughts. This page summarizes the posture; the role guides show how it plays out day to day.

Tenant isolation (Principle II)

• Site is the hard boundary. All data — users, departments, documents, conversations — is scoped by site_id and enforced server-side. A user never receives content or citations from outside their site.
• Departments are access groups (ABAC). On top of roles, retrieval is filtered to the departments a user belongs to; a user cannot retrieve documents from departments they're not in.
• Platform operators are separated from tenant data. Super Admins govern the platform but have an empty department scope and no branding/department/document permissions — they cannot view or retrieve any tenant's documents, and are excluded from department member lists (why).

Authentication & access control

• Authentication is handled by a managed identity platform (per-site identity tenants); the web app verifies sessions server-side.
• Role-based access control (Super/Site/Dept Admin, User) is enforced on the backend and, for retrieval, at query time — see the permission matrix. Least privilege is the default.

Grounded, non-fabricated answers (Principle I)

Answers are generated only from retrieved, in-scope source documents and always carry citations (document + location). The assistant will state when it cannot find an answer rather than fabricate one — accuracy is a first-class, measured requirement.

Secret protection & non-leakage (Principle III)

• No secrets in responses or logs. Sensitive links and credentials are never returned to administrators or written to logs/audit in plaintext.
• Onboarding links are out-of-band and single-use. The welcome email's password-setup link is generated out of band and used only for that email — it is never shown in the console/API, logged, or stored in the audit trail. If a user doesn't receive it, an admin re-sends via the standard password reset (no link is ever exposed to the admin).
• Secrets live in a managed secret store — never in source, logs, or client bundles.

Audit logging (Principle III)

• Administrative and data-access actions are recorded as content-free audit events (event type, site, user, timestamp — never document contents or secrets).
• The audit trail is tamper-evident: events are appended to a hash chain, so any modification or gap is detectable.
• Onboarding dispatch, provisioning, branding changes, membership changes, role assignments, and break-glass actions are all audited.

PDPA by design

• Data minimization & redaction — PII/PHI is kept out of logs and caches.
• Explicit, deliberate handling — e.g., document uploads require an explicit department selection (no default) so files can't be misfiled into the wrong access group.
• Data residency — processing respects region pinning.
• Full auditability — the trail above supports compliance review.

Accessibility

The interface targets WCAG 2.1 AA — including validated color-contrast for white-label brand colors, keyboard-operable controls (e.g., the collapsed-sidebar expand control is reachable by keyboard, not just hover), and reduced-motion support.