simstudioai · waleedlatif1 · Apr 21, 2026 · Apr 21, 2026 · Apr 21, 2026 · Apr 21, 2026
diff --git a/apps/docs/content/docs/en/enterprise/access-control.mdx b/apps/docs/content/docs/en/enterprise/access-control.mdx
@@ -0,0 +1,216 @@
+---
+title: Access Control
+description: Restrict which models, blocks, and platform features each group of users can access
+---
+
+import { Callout } from 'fumadocs-ui/components/callout'
+import { FAQ } from '@/components/ui/faq'
+import { Image } from '@/components/ui/image'
+
+Access Control lets organization admins define permission groups that restrict what each set of users can do — which AI model providers they can use, which workflow blocks they can place, and which platform features are visible to them. Restrictions are enforced both in the workflow executor and in Mothership.
+
+---
+
+## How it works
+
+Access control is built around **permission groups**. Each group has a name, an optional description, and a configuration that defines what its members can and cannot do. A user can belong to at most one permission group at a time.
+
+When a user runs a workflow or uses Mothership, Sim reads their group's configuration and applies it:
+
+- **In the executor:** If a workflow uses a disallowed block type or model provider, execution halts immediately with an error. This applies to both manual runs and scheduled or API-triggered deployments.
+- **In Mothership:** Disallowed blocks are filtered out of the block list so they cannot be added to a workflow. Disallowed tool types (MCP, custom tools, skills) are skipped if Mothership attempts to use them.
+
+---
+
+## Setup
+
+### 1. Open Access Control settings
+
+Go to **Settings → Enterprise → Access Control** in your workspace.
+
+<Image src="/static/enterprise/access-control-groups.png" alt="Access Control settings showing a list of permission groups: Contractors, Sales, Engineering, and Marketing, each with Details and Delete actions" width={900} height={500} />
+
+### 2. Create a permission group
+
+Click **+ Create** and enter a name (required) and optional description. You can also enable **Auto-add new members** — when active, any new member who joins the organization is automatically added to this group. Only one group per organization can have this setting enabled at a time.
+
+### 3. Configure permissions
+
+Click **Details** on a group, then open **Configure Permissions**. There are three tabs.
+
+#### Model Providers
+
+Controls which AI model providers members of this group can use.
+
+<Image src="/static/enterprise/access-control-model-providers.png" alt="Model Providers tab showing a grid of AI providers including Ollama, vLLM, OpenAI, Anthropic, Google, Azure OpenAI, and others with checkboxes to allow or restrict access" width={900} height={500} /> The list shows all providers available in Sim.
+
+- **All checked (default):** All providers are allowed.
+- **Subset checked:** Only the selected providers are allowed. Any workflow block or agent using a provider not on the list will fail at execution time.
+
+#### Blocks
+
+Controls which workflow blocks members can place and execute.
+
+<Image src="/static/enterprise/access-control-blocks.png" alt="Blocks tab showing Core Blocks (Agent, API, Condition, Function, Knowledge, etc.) and Tools (integrations like 1Password, A2A, Ahrefs, Airtable, and more) with checkboxes to allow or restrict each" width={900} height={500} /> Blocks are split into two sections: **Core Blocks** (Agent, API, Condition, Function, etc.) and **Tools** (all integration blocks).
+
+- **All checked (default):** All blocks are allowed.
+- **Subset checked:** Only the selected blocks are allowed. Workflows that already contain a disallowed block will fail when run — they are not automatically modified.
+
+<Callout type="info">
+  The `start_trigger` block (the entry point of every workflow) is always allowed and cannot be restricted.
+</Callout>
+
+#### Platform
+
+Controls visibility of platform features and modules.
+
+<Image src="/static/enterprise/access-control-platform.png" alt="Platform tab showing feature toggles grouped by category: Sidebar (Knowledge Base, Tables, Templates), Workflow Panel (Copilot), Settings Tabs, Tools, Deploy Tabs, Features, Logs, and Collaboration" width={900} height={500} /> Each checkbox maps to a specific feature; checking it hides or disables that feature for group members.
+
+**Sidebar**
+
+| Feature | Effect when checked |
+|---------|-------------------|
+| Knowledge Base | Hides the Knowledge Base section from the sidebar |
+| Tables | Hides the Tables section from the sidebar |
+| Templates | Hides the Templates section from the sidebar |
+
+**Workflow Panel**
+
+| Feature | Effect when checked |
+|---------|-------------------|
+| Copilot | Hides the Copilot panel inside the workflow editor |
+
+**Settings Tabs**
+
+| Feature | Effect when checked |
+|---------|-------------------|
+| Integrations | Hides the Integrations tab in Settings |
+| Secrets | Hides the Secrets tab in Settings |
+| API Keys | Hides the Sim Keys tab in Settings |
+| Files | Hides the Files tab in Settings |
+
+**Tools**
+
+| Feature | Effect when checked |
+|---------|-------------------|
+| MCP Tools | Disables the use of MCP tools in workflows and agents |
+| Custom Tools | Disables the use of custom tools in workflows and agents |
+| Skills | Disables the use of Sim Skills in workflows and agents |
+
+**Deploy Tabs**
+
+| Feature | Effect when checked |
+|---------|-------------------|
+| API | Hides the API deployment tab |
+| MCP | Hides the MCP deployment tab |
+| A2A | Hides the A2A deployment tab |
+| Chat | Hides the Chat deployment tab |
+| Template | Hides the Template deployment tab |
+
+**Features**
+
+| Feature | Effect when checked |
+|---------|-------------------|
+| Sim Mailer | Hides the Sim Mailer (Inbox) feature |
+| Public API | Disables public API access for deployed workflows |
+
+**Logs**
+
+| Feature | Effect when checked |
+|---------|-------------------|
+| Trace Spans | Hides trace span details in execution logs |
+
+**Collaboration**
+
+| Feature | Effect when checked |
+|---------|-------------------|
+| Invitations | Disables the ability to invite new members to the workspace |
+
+### 4. Add members
+
+Open the group's **Details** view and add members by searching for users by name or email. Users can only belong to one group at a time — adding a user to a new group removes them from their current one.
+
+---
+
+## Enforcement
+
+### Workflow execution
+
+Restrictions are enforced at the point of execution, not at save time. If a group's configuration changes after a workflow is built:
+
+- **Block restrictions:** Any workflow run that reaches a disallowed block halts immediately with an error. The workflow is not modified — only execution is blocked.
+- **Model provider restrictions:** Any block or agent that uses a disallowed provider halts immediately with an error.
+- **Tool restrictions (MCP, custom tools, skills):** Agents that use a disallowed tool type halt immediately with an error.
+
+This applies regardless of how the workflow is triggered — manually, via API, via schedule, or via webhook.
+
+### Mothership
+
+When a user opens Mothership, their permission group is read before any block or tool suggestions are made:
+
+- Blocks not in the allowed list are filtered out of the block picker entirely — they do not appear as options.
+- If Mothership generates a workflow step that would use a disallowed tool (MCP, custom, or skills), that step is skipped and the reason is noted.
+
+---
+
+## User membership rules
+
+- A user can belong to **at most one** permission group at a time.
+- Moving a user to a new group automatically removes them from their current group.
+- Users not assigned to any group have no restrictions applied (all blocks, providers, and features are available to them).
+- If **Auto-add new members** is enabled on a group, new organization members are automatically placed in that group. Only one group per organization can have this setting active.
+
+---
+
+<FAQ items={[
+  {
+    question: "Who can create and manage permission groups?",
+    answer: "Organization owners and admins can create, edit, and delete permission groups. On Sim Cloud, you must be on the Enterprise plan."
+  },
+  {
+    question: "What happens to a workflow that was built before a block was restricted?",
+    answer: "The workflow is not modified — it still exists and can be edited. However, any run that reaches a disallowed block will halt immediately with an error. The block must be removed or the user's group configuration must be updated before the workflow can run successfully."
+  },
+  {
+    question: "Can a user be in multiple permission groups?",
+    answer: "No. Each user can belong to at most one permission group at a time. Adding a user to a new group automatically removes them from their current one."
+  },
+  {
+    question: "What does a user see if they have no permission group assigned?",
+    answer: "Users with no group assignment have no restrictions. All blocks, model providers, and platform features are fully available to them."
+  },
+  {
+    question: "Does Mothership respect the same restrictions as the executor?",
+    answer: "Yes. Mothership reads the user's permission group before suggesting blocks or tools. Disallowed blocks are filtered out of the block picker, and disallowed tool types are skipped during workflow generation."
+  },
+  {
+    question: "Can I restrict access to specific workflows or workspaces?",
+    answer: "Access Control operates at the feature and block level, not at the individual workflow or workspace level. To restrict workspace access, use the organization membership and invitation settings."
+  },
+  {
+    question: "What is Auto-add new members?",
+    answer: "When a group has Auto-add new members enabled, any new member who joins the organization is automatically added to that group. Only one group per organization can have this setting enabled at a time."
+  }
+]} />
+
+---
+
+## Self-hosted setup
+
+Self-hosted deployments use environment variables instead of the billing/plan check.
+
+### Environment variables
+
+```bash
+ACCESS_CONTROL_ENABLED=true
+NEXT_PUBLIC_ACCESS_CONTROL_ENABLED=true
+```
+
+You can also set a server-level block allowlist using the `ALLOWED_INTEGRATIONS` environment variable. This is applied as an additional constraint on top of any permission group configuration — a block must be allowed by both the environment allowlist and the user's group to be usable.
+
+```bash
+# Only these block types are available across the entire instance
+ALLOWED_INTEGRATIONS=slack,gmail,agent,function,condition
+```
+
+Once enabled, permission groups are managed through **Settings → Enterprise → Access Control** the same way as Sim Cloud.
diff --git a/apps/docs/content/docs/en/enterprise/audit-logs.mdx b/apps/docs/content/docs/en/enterprise/audit-logs.mdx
@@ -0,0 +1,146 @@
+---
+title: Audit Logs
+description: Track every action taken across your organization's workspaces
+---
+
+import { Callout } from 'fumadocs-ui/components/callout'
+import { FAQ } from '@/components/ui/faq'
+import { Image } from '@/components/ui/image'
+
+Audit logs give your organization a tamper-evident record of every significant action taken across workspaces — who did what, when, and on which resource. Use them for security reviews, compliance investigations, and incident response.
+
+---
+
+## Viewing audit logs
+
+### In the UI
+
+Go to **Settings → Enterprise → Audit Logs** in your workspace. Logs are displayed in a table with the following columns:
+
+<Image src="/static/enterprise/audit-logs.png" alt="Audit Logs settings showing a table of events with columns for Timestamp, Event, Description, and Actor, along with search and filter controls" width={900} height={500} />
+
+| Column | Description |
+|--------|-------------|
+| **Timestamp** | When the action occurred. |
+| **Event** | The action taken, e.g. `workflow.created`. |
+| **Description** | A human-readable summary of the action. |
+| **Actor** | The email address of the user who performed the action. |
+
+Use the search bar, event type filter, and date range selector to narrow results.
+
+### Via API
+
+Audit logs are also accessible through the Sim API for integration with external SIEM or log management tools.
+
+```http
+GET /api/v1/audit-logs
+Authorization: Bearer <api-key>
+```
+
+**Query parameters:**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `action` | string | Filter by event type (e.g. `workflow.created`) |
+| `resourceType` | string | Filter by resource type (e.g. `workflow`) |
+| `resourceId` | string | Filter by a specific resource ID |
+| `workspaceId` | string | Filter by workspace |
+| `actorId` | string | Filter by user ID (must be an org member) |
+| `startDate` | string | ISO 8601 date — return logs on or after this date |
+| `endDate` | string | ISO 8601 date — return logs on or before this date |
+| `includeDeparted` | boolean | Include logs from members who have since left the organization (default `false`) |
+| `limit` | number | Results per page (1–100, default 50) |
+| `cursor` | string | Opaque cursor for fetching the next page |
+
+**Example response:**
+
+```json
+{
+  "data": [
+    {
+      "id": "abc123",
+      "action": "workflow.created",
+      "resourceType": "workflow",
+      "resourceId": "wf_xyz",
+      "resourceName": "Customer Onboarding",
+      "description": "Created workflow \"Customer Onboarding\"",
+      "actorId": "usr_abc",
+      "actorName": "Alice Smith",
+      "actorEmail": "alice@company.com",
+      "workspaceId": "ws_def",
+      "metadata": {},
+      "createdAt": "2026-04-20T21:16:00.000Z"
+    }
+  ],
+  "nextCursor": "eyJpZCI6ImFiYzEyMyJ9"
+}
+```
+
+Paginate by passing the `nextCursor` value as the `cursor` parameter in the next request. When `nextCursor` is absent, you have reached the last page.
+
+<Callout type="info">
+  The API accepts both personal and workspace-scoped API keys. Rate limits apply — the response includes `X-RateLimit-*` headers with your current limit and remaining quota.
+</Callout>
+
+---
+
+## Event types
+
+Audit log events follow a `resource.action` naming pattern. The table below lists the main categories.
+
+| Category | Example events |
+|----------|---------------|
+| **Workflows** | `workflow.created`, `workflow.deleted`, `workflow.deployed`, `workflow.locked` |
+| **Workspaces** | `workspace.created`, `workspace.updated`, `workspace.deleted` |
+| **Members** | `member.invited`, `member.removed`, `member.role_changed` |
+| **Permission groups** | `permission_group.created`, `permission_group.updated`, `permission_group.deleted` |
+| **Environments** | `environment.updated`, `environment.deleted` |
+| **Knowledge bases** | `knowledge_base.created`, `knowledge_base.deleted`, `connector.synced` |
+| **Tables** | `table.created`, `table.updated`, `table.deleted` |
+| **API keys** | `api_key.created`, `api_key.revoked` |
+| **Credentials** | `credential.created`, `credential.deleted`, `oauth.disconnected` |
+| **Organization** | `organization.updated`, `org_member.added`, `org_member.role_changed` |
+
+---
+
+<FAQ items={[
+  {
+    question: "Who can view audit logs?",
+    answer: "Organization owners and admins can view audit logs. On Sim Cloud, you must be on the Enterprise plan."
+  },
+  {
+    question: "Are audit logs tamper-proof?",
+    answer: "Audit log entries are append-only and cannot be modified or deleted through the Sim interface or API. They represent a reliable record of actions taken in your organization."
+  },
+  {
+    question: "Can I export audit logs?",
+    answer: "Yes. Use the API to export logs programmatically. Paginate through all records using the cursor parameter and store them in your own data warehouse or SIEM."
+  },
+  {
+    question: "Are logs scoped to a single workspace or the whole organization?",
+    answer: "Audit logs are scoped to your organization and include activity across all workspaces within it. You can filter by workspaceId to narrow results to a specific workspace."
+  },
+  {
+    question: "What information is included in each log entry?",
+    answer: "Each entry includes the event type, a description, the actor's name and email, the affected resource, the workspace, and a timestamp. IP addresses and user agents are not exposed through the API."
+  },
+  {
+    question: "Can I filter logs by a specific user?",
+    answer: "Yes. Pass the actorId query parameter to filter logs by a specific user. The actor must be a current or former member of your organization."
+  }
+]} />
+
+---
+
+## Self-hosted setup
+
+Self-hosted deployments use environment variables instead of the billing/plan check.
+
+### Environment variables
+
+```bash
+AUDIT_LOGS_ENABLED=true
+NEXT_PUBLIC_AUDIT_LOGS_ENABLED=true
+```
+
+Once enabled, audit logs are viewable in **Settings → Enterprise → Audit Logs** and accessible via the API.