🔐 Security Profiles
Configure user access to platform modules, Knowledge Nodes, DataApps, dashboards, and API collections.
🔐 Security Profile Overview
Security profiles in ARPIA are critical for maintaining a secure and compliant environment for data management and collaboration. These profiles provide a structured framework for controlling access and permissions, ensuring that organizational data is protected and only accessible to authorized individuals. Implementing robust security practices and leveraging configurable access controls promotes responsible and secure use of the ARPIA platform.
🔑 How Security Profiles Work
A Security Profile is a named, reusable permission set that is assigned to users at the Workarea level. Rather than configuring permissions per individual user, administrators define profiles once and apply them across multiple users — keeping access management consistent and auditable.
Key characteristics:
- Workarea-scoped — profiles apply within a specific Workarea; a user invited to multiple Workareas can hold a different profile in each.
- Named and versioned — every profile has a human-readable name, a unique ID, and a full audit trail of permission changes.
- Profile-grouped user list — the Users view groups users by their assigned profile, making it easy to see who has what access at a glance.
📋 The Security Profiles List
Navigate to Admin → Users & Security → Security Profiles to view all profiles in your Workarea.
Each row in the list shows:
| Column | Description |
|---|---|
| Profile | Profile name and unique ID |
| Created | Timestamp and creator |
| Users | Number of users currently assigned to this profile |
| Status | Active or inactive |
| Actions | Edit Name, View Audit, Edit Permissions |
From this view administrators can create new profiles using the + button, rename existing ones, review the change history, or update the permission set.
Default profile
When a Workarea is created for the first time, a Super User profile is automatically generated. This is the only system-created profile — all additional profiles are created and named by administrators according to their organization's needs.
Common profile archetypes
The following represent best practice access tiers commonly used in ARPIA deployments. Profile names are entirely up to each organization — what matters is the permission set behind the name, not the label itself.
| Profile | Typical use case |
|---|---|
| End-User | Consumers of AI Apps and Dashboards only — no platform configuration access |
| Data Analyst | Access to Reasoning Knowledge, Query Tool, Data Objects, DataApps and Dashboards — no build or admin access |
| App Developer | Access to AI Apps Studio, Reasoning Flows, Data Workshop, Resources, AutoAPI, App Droplets — no security or billing access |
| Platform Admin | Full platform module access including Security Settings and User Management — no billing or WorkArea creation |
| AI Governance Officer | Access to AI Governance module, Reasoning Knowledge (read), Aerie, Policy Center, Risk & Compliance, Logs — observer/compliance role |
🕵️ Profile Audit Trail
Every Security Profile maintains a complete version history accessible via View Audit. Each saved state of a profile is recorded with a timestamp and the email of the user who made the change.
Version selector
Selecting View Audit opens a modal listing all saved versions of the profile in reverse chronological order — each entry shows the exact date, time, and the administrator who saved that version.
Diff view
Selecting a version loads a side-by-side diff comparing the selected historical version (left) against the current configuration (right). Added permissions are highlighted in green. The diff also surfaces profile renames, marked with a RENAMED badge.
This makes it possible to answer precisely: what changed, when, and who made the change — down to the individual permission flag.
Compliance framework alignment
| Framework | Relevant Control Area | How the Audit Trail Supports It |
|---|---|---|
| SOC 2 Type 2 | CC6.1, CC6.2, CC6.3 — Logical access controls | Demonstrates that access is granted, modified, and revoked with a traceable, attributed history |
| ISO/IEC 27001 | A.9 — Access control | Provides evidence of access management policy enforcement and change logging |
| ISO/IEC 42001 | 6.1, 8.4 — AI risk controls and operational processes | Supports auditability of who has access to AI reasoning assets and governance modules |
| GDPR | Article 5(2), Article 25 — Accountability and data protection by design | Documents the access control decisions applied to personal data processing functions |
| HIPAA | §164.312(a)(1) — Access control; §164.312(b) — Audit controls | Provides the timestamped, user-attributed access change log required for covered entity compliance |
| NIST AI RMF | GOVERN 1.2, MANAGE 2.2 — Accountability and risk tracking | Supports traceability of access decisions to AI platform components |
| DORA | Article 9 — ICT security; Article 13 — ICT change management | Provides a versioned, attributed record of permission changes as part of ICT change control evidence |
⚙️ Permission Dimensions
Each profile is configured across five tabs. Permissions are additive — only what is explicitly enabled is accessible to the user.
1. Access to Dashboards
Controls access to Dashboard-type screens within AI Apps. When an AI App contains one or more Dashboard screens, those screens are surfaced here for granular access control.
Each app is listed with a (granted/total) counter showing how many of its Dashboard screens are currently enabled for this profile. Expanding an app reveals individual screen checkboxes, plus an "Access to all screens of this DataApp" master toggle for a quick full-access grant, and select-all / deselect-all bulk controls.
Because AI Apps can contain screens nested inside other screens or hidden from the main navigation, the list reflects the full screen inventory — not just top-level visible screens. An app with 0 granted screens remains in the list but its Dashboard screens are inaccessible to users under this profile.
2. Access to DataApps
Controls access to all non-Dashboard screen types within AI Apps — including Page Layout, AI Assistant, Calendar, Map, Data Forms Insights, Custom screens, and others.
Like the Dashboards tab, access is managed at the individual screen level. Each app shows a (granted/total) counter; expanding it reveals all screens with individual checkboxes, an "Access to all screens of this DataApp" master toggle, and bulk select/deselect controls.
The list grows in proportion to the number of apps and screens in the Workarea — a single app can contain dozens of screens including hidden and nested sub-screens. The counter makes it easy to audit which apps have partial vs. full access for a given profile.
3. Access to Reasoning Knowledge
Controls access to Knowledge Nodes at the node and group level. Nodes are displayed in collapsible groups (e.g. a group of 11 nodes shows as 0/11), and administrators can enable access to individual nodes within each group.
This is the most granular access layer in ARPIA — enabling precise control over which knowledge assets each profile can read and reason over.
4. MCP / API Collection
Controls which MCP and API Collections are exposed to users under this profile. Collections appear under Available Collections and can be enabled individually.
5. Administrative Settings
Controls access to platform modules and administrative capabilities. Permissions are organized into three categories:
Arpia AI Platform (21 flags)
| Permission | Description |
|---|---|
| Access to Orchestrator | Access to the AI Orchestrator module and its configuration |
| Access to Resources | Access to the Resources section (databases, storage, connections) |
| Access to DataApp Studio | Access to build and edit AI Apps in the AI Apps Studio |
| Access to Data Sources | Access to configure and manage Data Sources |
| Access to Data Objects | Access to create and manage Data Objects (tables, views, triggers, functions) |
| Access to Data Pipes | Access to create and manage Data Pipes |
| Access to Kubes Models | Access to Data Models (Kubes/Nodes) configuration |
| Access to AutoAPI | Access to create and manage AutoAPI endpoints |
| Access to App Droplets | Access to create and manage App Droplets |
| Access to Data Forms | Access to create and manage Data Forms |
| Access to Alert Rules | Access to create and manage Alert Rules |
| Access to Integrations | Access to configure third-party integrations |
| Access to Data Workshop | Access to Reasoning Flows and Workshop Projects |
| Admin access to any workshop projects | Grants administrative access to all Workshop Projects in the Workarea, regardless of ownership |
| Access to WorkArea Migration Tool | Access to the tool for migrating Workarea content |
| Access to DataPoints Tool | Access to the DataPoints configuration tool |
| AI Governance | Access to the AI Governance module (Aerie, Policy Center, Risk & Compliance, Logs) |
| Access to Actions | Access to create and manage Actions |
| Access to Node Requests | Access to review and manage Knowledge Node access requests |
| Access to SPA Studio | Access to the Single Page Application (SPA) Studio |
| Build Personal Applications | Ability to build and deploy personal applications within the Workarea |
Security Options (3 flags)
| Permission | Description |
|---|---|
| Access to Security Settings | Access to the Security Profiles configuration section |
| Access to Users | Access to the Users management section |
| Access to Users Sessions | Access to view and manage active user sessions |
Other Options (6 flags)
| Permission | Description |
|---|---|
| Access to AI Governance | Access to AI Governance features from this context (cross-listed with platform flags) |
| Access to Support Chat | Access to the in-platform support chat |
| Access to Billing and Accounts | Access to billing information and account management |
| Create new WorkArea | Ability to create new Workareas |
| Access to edit workarea | Ability to edit Workarea settings and configuration |
| Access to Screen Snapshots | Access to the Screen Snapshots feature |