Assenture

Access Controls Policy

Last updated: August 8, 2026

This policy defines how access to Assenture systems, production infrastructure and customer data is granted, enforced, reviewed and revoked. It applies to all Assenture personnel and contractors, to all production and pre-production environments, and to the access controls we make available to customers inside the product. It supports and is read together with our Security Policy, Privacy Policy and Data Processing Addendum.

1. Principles

  • Least privilege. Every identity receives the minimum access required for its function, for the shortest practical duration.
  • Deny by default. Data is inaccessible unless a policy explicitly permits it. New tables and endpoints ship closed.
  • Separation of duties. The ability to grant access is separated from the ability to use elevated access unsupervised; privilege changes are logged and notified.
  • Accountability. Every action is attributable to a named individual. Shared or generic accounts are prohibited.
  • Defence in depth. Authorisation is enforced at the database layer, not only in the user interface.

2. Identity and authentication

  • Customer authentication uses email and password (hashed with bcrypt by our managed auth provider) or Google OAuth 2.0 / OIDC. Passwords are never stored in plaintext and are not retrievable by staff.
  • Password credentials are checked against known-breach corpora at registration and change time; compromised passwords are rejected.
  • Customer accounts support phishing-resistant multi-factor authentication: WebAuthn / FIDO2 passkeys, including platform biometrics (Face ID, Touch ID, Windows Hello) and hardware security keys. Credentials are origin-bound, so they cannot be replayed against a lookalike site. Time-based one-time codes from an authenticator app are offered as a fallback factor.
  • Where a verified factor exists, a session that has not satisfied it is blocked from every authenticated surface until the challenge is completed.
  • High-risk actions require step-up authentication evaluated at the moment of the action. In particular, linking, syncing or disconnecting a financial account through our bank aggregation partner requires an elevated (second-factor) session; the aggregator's link flow is not surfaced to a single-factor session.
  • Sessions are bearer-token based with short-lived access tokens and rotating refresh tokens. Tokens are transmitted only over TLS 1.3 and are invalidated on sign-out.
  • Internal access to production is through a single corporate identity provider with SSO and mandatory multi-factor authentication using phishing-resistant hardware keys (WebAuthn / FIDO2).
  • Machine-to-machine access uses scoped API keys or OAuth-protected endpoints (including our agent/MCP surface). Keys are per-integration, revocable, and never shared between environments.

3. Authorisation model inside the product

Assenture is multi-tenant. The workspace is the unit of access. Authorisation is enforced by row level security policies in the database, so the same rules apply to the web application, the API and any agent integration.

  • Roles. Each workspace defines roles (for example Owner, Admin, Finance, HR, Member). Roles are stored in dedicated role tables, never as an attribute on a user or profile record, which prevents privilege escalation through profile updates.
  • Granular permissions. Roles are composed from a fixed catalogue of module permissions (for example books.invoices.create, payroll.view_compensation, employees.terminate, roles.manage). Permission checks are evaluated server side by security-definer functions.
  • Data scopes. Sensitive domains (finance, payroll, HR, executive) are additionally scoped so that membership of a workspace alone does not grant visibility of compensation or banking data.
  • Ownership controls. Only a verified workspace owner may transfer ownership or grant owner-level rights; policy checks explicitly block indirect escalation through membership or role-permission edits.
  • AI and automation. Automated agents act strictly within the permissions of the user who invoked them and require explicit confirmation for consequential actions. They cannot exceed that user's rights.

4. Provisioning, changes and de-provisioning

  • Access is requested by the individual's manager (internally) or a workspace admin (in-product) and granted only against a defined role, never ad hoc.
  • New joiners receive a baseline role with no production data access. Elevated production access requires documented approval from engineering leadership.
  • Role changes (movers) trigger removal of the prior entitlement set at the same time the new one is granted; entitlements are replaced, not accumulated.
  • Leavers are de-provisioned automatically: identity provider deactivation cascades to all federated systems, revoking sessions, tokens and keys. Target completion is within 4 hours of notification and always the same business day.
  • Customer-side, admins can suspend or remove a member immediately; suspension invalidates active sessions and API keys tied to that member.

5. Privileged and administrative access

  • Production data access by staff is limited to a small number of named engineers, requires SSO with hardware MFA, and is logged.
  • Service-role and administrative database credentials are never exposed to client code and are never used to decide whether a caller is an administrator.
  • Administrative operations run through auditable code paths that verify the caller's identity and role before executing.
  • Standing access to customer content is avoided; access for support or incident investigation is limited to what is strictly necessary and is recorded.

6. Secrets and key management

  • API keys, signing secrets and database credentials are held in an encrypted secret store, scoped per environment, and injected at runtime. They are never committed to source control.
  • Customer-supplied integration credentials are encrypted at rest with a key separate from the application database.
  • Keys are rotated on a scheduled basis and immediately on suspected compromise or personnel departure.

7. Logging, monitoring and review

  • Authentication events, role and permission changes, membership changes and administrative actions are written to an immutable audit log that records the actor, the target, the change and the timestamp. Workspace admins can review their own audit log in-product.
  • Security-sensitive changes (for example granting owner rights or altering role permissions) additionally notify workspace owners.
  • We alert on anomalous patterns such as repeated failed logins, unusual export volumes and unexpected privilege escalation.
  • Access reviews: internal production entitlements are reviewed quarterly; privileged entitlements are reviewed monthly. Workspace admins are prompted to review member roles periodically. Findings are remediated within 10 business days.

8. Network and endpoint conditions

  • All access to production is over TLS; plaintext protocols are disabled.
  • Administrative interfaces are not exposed publicly without authentication, and public API endpoints validate signatures or shared secrets before performing any action.
  • Staff devices used for production access are company-managed, full-disk encrypted, screen-locked, patched and running endpoint protection.

9. Exceptions

Any deviation from this policy requires documented approval from engineering leadership, a stated compensating control and an expiry date. Exceptions are re-evaluated at each access review and expire automatically if not renewed.

10. Enforcement and ownership

This policy is owned by Assenture engineering leadership, reviewed at least annually and after any material change to our architecture or any security incident. Violations may result in revocation of access and disciplinary or contractual action. Questions and assurance requests can be sent to business@assenture.app.