Workspaces, Roles & Governance in AI Insights 365

Effective governance in AI Insights 365 — On-Prem Edition starts with a clear understanding of how the platform partitions people, projects, and data. The product is multi-tenant by design: a single on-premises deployment can host many Organizations, each containing one or more Workspaces that own their own datasources, AI agents, dashboards, and reports. This reference explains the org-to-workspace model, walks through creating and organizing workspaces, shows how to assign and inherit roles, and describes how audit logs and backups support recurring governance reviews. Every control described here runs entirely within your own infrastructure.

The Organization-to-Workspace Model

AI Insights 365 uses a two-tier tenancy model. The Organization is the top-level boundary. Users belong to an organization and can only see the resources within it — there is no cross-organization visibility. Inside an organization, work is divided into Workspaces.

A workspace is an isolated project boundary. Each workspace owns its own:

• Datasources — the connectors and database credentials it queries (across 30+ supported connectors).
• AI agents — the NL-to-SQL agents and assistants scoped to that workspace's data.
• Dashboards and reports — including the 72+ chart types, scheduled reports, and auto-generated reports built from workspace data.
• Transforms — data preparation logic that stays local to the workspace.

Because these resources are owned at the workspace level, a user with access to one workspace cannot see or query the datasources, agents, or reports of another workspace unless they are explicitly granted membership there. This is the foundation of resource isolation, and it is what makes the platform safe to use for multiple teams, clients, or business units on a single deployment.

Why two tiers matter for governance

The two-tier model maps cleanly onto how most organizations think about responsibility:

• The organization corresponds to a legal entity, a customer, or a tenant whose data must never commingle with another.
• The workspace corresponds to a project, a department, or an engagement with its own data, its own audience, and its own access list.

This separation lets you grant broad autonomy inside a workspace while guaranteeing hard isolation between them.

Creating and Organizing Workspaces

Plan your workspace structure before you create resources. A workspace is the unit of isolation, so the boundaries you draw here determine who can see what for the life of the deployment.

To create a workspace:

1. Sign in to the organization as a user with organization-level administrative rights.
2. Open the Workspaces area for your organization.
3. Select Create Workspace and give it a clear, durable name that reflects its purpose (for example, Finance — Reporting or Client Acme — Analytics).
4. Add an optional description so reviewers understand the workspace's scope at a glance.
5. Save. The workspace is created empty, with no datasources, agents, or reports until you add them.

After creation, populate the workspace:

1. Add datasources by configuring connectors. Where the source is a database, connect directly to it in-network — over private networking or VPN if it lives in a remote subnet — using a least-privilege, read-only account so credentials remain in your network.
2. Configure AI agents to query those datasources using natural language.
3. Build dashboards and reports, and schedule any recurring deliveries.

Recommended organizing principles

• One isolation boundary, one workspace. If two groups of data must never be visible to the same people, put them in separate workspaces.
• Name for longevity. Use names that survive reorganizations — function or client names age better than individual team names.
• Keep production and experimentation apart. A sandbox workspace lets editors explore without touching governed, scheduled reports.
• Avoid over-fragmentation. Too many tiny workspaces complicates membership reviews. Group related work where isolation is not required.

Roles: Admin, Editor, and Viewer

Within a workspace, every member holds one of three roles. Roles are scoped to the workspace — a user can be an Admin in one workspace and a Viewer in another within the same organization.

Roles capability table

In short: Viewers consume, Editors build, and Admins govern. Apply the principle of least privilege — grant the lowest role that lets a person do their job, and reserve Admin for the few people accountable for the workspace.

Group-Driven Membership with AD / Entra

Managing membership user-by-user does not scale and tends to drift out of compliance. AI Insights 365 integrates with Active Directory / Microsoft Entra so that membership is driven by security groups rather than individual assignments.

How it works:

1. An Admin maps an AD/Entra security group to a workspace and assigns that mapping a role (Admin, Editor, or Viewer).
2. Every user in that security group inherits the mapped role in the workspace automatically.
3. When a person joins or leaves the group in your directory, their workspace access follows — no manual change inside the platform is required.

This delivers several governance benefits:

• Single source of truth. Access decisions live in your directory, where joiner-mover-leaver processes already operate.
• Inherited roles. Group membership confers the role, so role changes are made once at the group level.
• Auditable provisioning. Because access is group-derived, an access review becomes a review of group membership and group-to-role mappings.

When mapping groups, keep mappings explicit and few. A workspace mapped to one group per role is far easier to review than one mapped to many overlapping groups. Combined with AD/Entra SSO, this gives you centralized authentication and centralized authorization in one flow.

Resource Isolation in Practice

Resource isolation is enforced at the workspace boundary and reinforced by the platform's security posture:

• Data never leaves your infrastructure. The platform runs entirely on-prem, and for the most sensitive environments the AI layer can run fully air-gapped against a local Ollama model.
• Credentials stay in-network. The platform connects directly to your in-network databases (reaching remote subnets over private networking or VPN), so database credentials never leave your network; workspaces reference datasources without exposing secrets.
• Secrets are encrypted at rest. AES-256 encryption protects stored secrets, with a rotatable key.
• Queries are constrained. AI-generated queries run read-only in a sandbox, so an agent cannot mutate source data.
• Embeds are scoped. Report embed tokens are signed and scoped, so a shared report cannot be used to reach beyond its intended data.

Together these mean that workspace isolation is not only a UI convention — it is backed by credential, encryption, and query-execution controls.

Using the Audit Log for Governance Reviews

The audit log is the backbone of recurring governance. It captures per-user actions — including create, edit, delete, and access events — and is queryable by organization, user, and time range.

Use it to answer the questions governance reviews require:

• Who accessed what, and when? Filter by user and time window to reconstruct activity for a review period.
• What changed in a sensitive workspace? Filter by action type to surface every create, edit, and delete.
• Did access match policy? Cross-reference active membership (and the groups that confer it) against actual access events.

A practical quarterly review workflow:

1. Define the review period and the workspaces in scope.
2. Pull the audit log for those workspaces, filtered by the period.
3. Confirm that every user who took actions still has a legitimate role, tracing each back to its AD/Entra group mapping.
4. Investigate any access by users who should no longer have it, and remediate at the group level.
5. Record the review outcome and retain the exported log as evidence.

Because the audit trail records access as well as changes, it supports both security investigations and the access-recertification cycles that compliance programs expect.

Backup and Restore for Governance and Portability

AI Insights 365 provides backup and restore at two levels, each producing a ZIP archive:

• Organization backup (.orgbak) — captures the organization and its workspaces.
• Workspace backup (.wbak) — captures a single workspace and its resources.

Both archive types can be restored into the same deployment or a different deployment, which makes them useful for far more than disaster recovery:

• Portability. Move a workspace between environments — for example, promoting a configuration from a staging deployment to production — without rebuilding it by hand.
• Tenant offboarding and handover. Export an organization or workspace as a self-contained archive to hand to its owner.
• Point-in-time governance snapshots. Capture the state of a workspace before a significant change so you can demonstrate what existed at a given time.
• Disaster recovery. Restore an organization or workspace after a failure.

To back up a workspace:

1. As a workspace Admin, open the workspace settings.
2. Select Backup and download the generated .wbak archive.
3. Store the archive according to your retention policy.

To restore:

1. In the target deployment, choose to restore from a .wbak (or .orgbak) file.
2. Upload the archive and confirm the target organization.
3. Verify membership mappings and datasource credentials after restore, since the new environment may use different directory groups or different in-network database endpoints (including private-network or VPN routes to remote subnets).

A Recommended Governance Structure

Bringing the pieces together, a defensible governance structure for most deployments looks like this:

• Organizations mirror legal or tenant boundaries, ensuring hard data separation.
• Workspaces mirror projects or departments, each owning its datasources, agents, and reports.
• AD/Entra security groups drive all membership, with one group per role per workspace and roles inherited from the group.
• Least-privilege roles are the default — Viewer unless a build or govern need is demonstrated.
• Quarterly audit-log reviews recertify access and document changes, tracing every active role to a group mapping.
• Scheduled backups (.orgbak and .wbak) provide recovery, portability, and point-in-time evidence.

This structure keeps authority centralized in your directory, keeps data isolated by design, and produces the access and change evidence that governance and compliance teams rely on — all without any data leaving your infrastructure.

Common Governance Scenarios

The model above is flexible enough to handle the situations governance teams encounter most often. A few worked examples make the intended patterns concrete.

Onboarding a new department

When a new department needs analytics, create a dedicated workspace rather than adding the team to an existing one. Map the department's existing AD/Entra security groups to the new workspace — typically a managers group as Editor and a broader staff group as Viewer — and add the workspace's datasources via direct, in-network database connections using least-privilege read-only accounts. Because membership is group-derived, the department's normal joiner process now automatically grants and revokes access without any per-user work inside the platform.

Separating a client engagement

For agencies or service providers, each client should map to its own organization so that no user can ever see across client boundaries. Within that organization, create workspaces per engagement or deliverable. At the end of an engagement, export the workspace as a .wbak archive to hand to the client, then remove the group mappings to revoke all access in a single step.

Recertifying access after a reorganization

After a reorganization, directory groups often change shape. Because the platform inherits roles from those groups, most access updates happen automatically. The governance task that remains is to review the group-to-role mappings themselves: confirm that each mapped group still corresponds to a population that should hold its assigned role, and pull the audit log to verify that recent activity is consistent with the new structure.

Investigating an incident

When a potential incident arises, the audit log is the first stop. Filter by the affected workspace and time window, then by action type, to reconstruct exactly which users accessed, created, edited, or deleted resources. Because every action is attributed to a user and every user traces back to a group mapping, you can move quickly from "what happened" to "who had access and why."

Operational Best Practices

To keep the governance model healthy over time:

• Review mappings on a schedule, not just on change. Even with group-driven access, mappings drift as groups are repurposed. A periodic review catches groups that have outgrown their original role.
• Rotate the encryption key per policy. The AES-256 key protecting stored secrets is rotatable; align rotation with your key-management standard.
• Test restores, not just backups. A .wbak or .orgbak archive is only as good as your ability to restore it. Periodically restore into a non-production deployment to validate the archive and rehearse recovery.
• Keep Admin counts low. The fewer workspace Admins, the smaller the population that can change membership, mappings, and backups. Treat Admin as a privileged role subject to its own review.
• Document the intended structure. A short, maintained description of which organizations and workspaces exist and why turns every future access review into a comparison against a known baseline rather than a discovery exercise.

Followed consistently, these practices ensure that the isolation, role, audit, and backup capabilities described above continue to deliver defensible governance as the deployment grows.