AI Permission Management

1. Background and Goals

AI chat will gradually gain capabilities such as conversation, file reading, external network access, data read/write, app design, app publishing, and team administration. To let AI work safely in enterprise scenarios, the platform needs a permission system that is clear, explainable, and auditable.

This design divides AI permissions into two layers:

1. Team role layer: configured by team administrators. It defines the maximum AI capabilities that a team role can grant.
2. Personal session layer: selected by the user in each session. It defines the AI capabilities that are actually available in the current session.

Both layers take effect together. The personal session layer cannot exceed the authorization range of the team role layer; it can only further narrow the capabilities already granted by the team role.

2. Design Principles

2.1 Least privilege by default

AI only has the minimum capabilities needed for basic conversation by default. High-risk actions such as writing data, changing design, publishing apps, managing members, and changing team configuration must be explicitly authorized.

2.2 Role authorization is the upper bound

The team role layer defines the upper bound of permissions. Even if a user selects a higher session mode, AI cannot perform actions beyond the permissions granted to the current role.

2.3 Session mode is the current authorization

The personal session layer defines the actual permission scope for the current session. Users can choose Read-only Mode, Data Mode, Design Mode, or Admin Mode within the scope allowed by their current role.

2.4 Secondary confirmation for high-risk actions

Creating data, updating data, deleting data, changing design, creating apps, deleting apps, publishing apps, managing app members, and managing teams are high-risk capabilities. Even when both the role layer and session layer allow them, secondary confirmation is still required before execution.

2.5 End-to-end auditability

AI permission configuration, session mode selection, tool calls, data changes, design changes, and administration actions should all be logged for traceability, troubleshooting, and risk review.

3. Layered Permission Model

3.1 Team role layer

The team role layer controls the AI permissions available to different team roles. It is configured by administrators and answers the question: what is the maximum scope of actions AI may perform for this role?

Permission Template	Use Case	Typical Capabilities
Read-only Assistant	For regular members, guests, and users who only need query and Q&A capabilities	Chat, upload files, access external network, read data, read design
Data Assistant	For business operations and data maintenance users	Read-only Assistant capabilities plus create data, update data, delete data
Design Assistant	For app builders, implementation users, and configuration developers	Read-only Assistant capabilities plus update design, create app, delete app
Admin Assistant	For app administrators and team administrators	Read-only Assistant capabilities plus publish app, manage app members, manage team
Custom	For fine-grained permission control	Administrators configure each capability individually

Permission templates are only configuration shortcuts. The final stored result is still a concrete list of capabilities, and administrators can continue to fine-tune it after selecting a template.

3.2 Personal session layer

The personal session layer controls the AI capabilities that can actually be used in the current session. It is selected by end users when starting or working in a session.

Session Mode	Description	Use Case
Read-only Mode	Allows conversation, file upload, external network access, and reading data/design within the role authorization scope	Q&A, analysis, troubleshooting, read-only work
Data Mode	Allows reading and writing business data based on Read-only Mode	Data entry, data correction, batch maintenance
Design Mode	Allows changing app configuration, scripts, APIs, table structure, and other design content based on Read-only Mode	App building, page adjustment, workflow and API configuration
Admin Mode	Allows publishing apps, managing app members, and team configuration based on Read-only Mode	App release, member authorization, team-level configuration

Session mode does not grant permissions that the role does not have. For example, if a user's team role does not have Delete Data permission, AI cannot delete data even when the user selects Data Mode.

4. Permission Capabilities

AI permissions are grouped into basic permissions, data permissions, design permissions, and administration permissions.

4.1 Basic permissions

Permission	Description	Risk Level
Chat	Allows starting and continuing AI sessions	Low
Upload Files	Allows uploading attachments for AI to read in the session	Medium
Access External Network	Allows AI to access external URLs or remote MCP services	Medium

4.2 Data permissions

Permission	Description	Risk Level
Read Data	Allows AI to query table structures, business records, and statistics	Medium
Create Data	Allows AI to create business data	High
Update Data	Allows AI to update existing business data	High
Delete Data	Allows AI to delete business data	High

Data permissions only control whether AI may initiate the corresponding actions. The actual data scope must still respect existing app permissions, table permissions, field permissions, and data scope permissions.

4.3 Design permissions

Permission	Description	Risk Level
Read Design	Allows AI to view app definitions such as pages, tables, scripts, and APIs	Medium
Update Design	Allows AI to change pages, scripts, APIs, table structure, and other app definitions	High
Create App	Allows AI to create new apps	High
Delete App	Allows AI to delete apps	High

4.4 Administration permissions

Permission	Description	Risk Level
Publish App	Allows AI to publish an app to the production environment	High
Manage App Members	Allows AI to adjust app members and roles	High
Manage Team	Allows AI to handle team-level management configuration	High

Administration permissions are the highest-risk capabilities. They should be disabled by default, granted only to trusted administrator roles, and protected by secondary confirmation and audit logs.

5. Permission Calculation Rules

The final permissions available to AI are determined by the team role permissions, personal session mode, existing business permissions, and system security policies.

Final AI executable permissions = Team role AI permissions ∩ Personal session mode permissions ∩ User business permissions ∩ System security policies

• Team role AI permissions define the upper bound of AI capabilities.
• Personal session mode permissions define which AI capabilities are enabled in the current session.
• User business permissions define whether the user is allowed to access the target app, table, record, field, or management feature.
• System security policies block high-risk actions, unauthorized access, abnormal batch operations, and unconfirmed actions.

5.1 Users with multiple roles

When a member has multiple team roles, the team role permissions should be calculated as a union. The member receives the maximum AI permission scope granted by any of their roles.

Team role AI permissions = Role A permissions ∪ Role B permissions ∪ ... ∪ Role N permissions

Token quotas can also use the maximum quota to avoid a lower-quota role accidentally limiting a member who has multiple roles.

5.2 Session mode downgrade

If the selected session mode includes capabilities that the current role does not grant, the system should not block the entire session. Instead, it should automatically downgrade to the available capability scope and show a prompt.

Example:

• The user selects Data Mode.
• The current role only has Read Data, not Create Data, Update Data, or Delete Data.
• AI can read data in this session but cannot create, update, or delete data.

5.3 High-risk confirmation

The following capabilities require secondary confirmation before execution:

• Create data.
• Update data.
• Delete data.
• Update design.
• Create app.
• Delete app.
• Publish app.
• Manage app members.
• Manage team.

The confirmation should include the action, affected object, change summary, risk warning, and confirm/cancel actions. For batch data changes, app deletion, production publishing, and team administration, the system may require confirmation text input or another administrator authorization.

6. Session Mode and Capability Mapping

Capability	Read-only Mode	Data Mode	Design Mode	Admin Mode
Chat	Supported	Supported	Supported	Supported
Upload Files	Supported	Supported	Supported	Supported
Access External Network	Supported	Supported	Supported	Supported
Read Data	Supported	Supported	Supported	Supported
Create Data	Not supported	Supported	Not supported	Not supported
Update Data	Not supported	Supported	Not supported	Not supported
Delete Data	Not supported	Supported	Not supported	Not supported
Read Design	Supported	Supported	Supported	Supported
Update Design	Not supported	Not supported	Supported	Not supported
Create App	Not supported	Not supported	Supported	Not supported
Delete App	Not supported	Not supported	Supported	Not supported
Publish App	Not supported	Not supported	Not supported	Supported
Manage App Members	Not supported	Not supported	Not supported	Supported
Manage Team	Not supported	Not supported	Not supported	Supported

Supported means the session mode allows the capability, but the team role layer and existing business permissions must also allow it.

7. Page and Interaction Suggestions

7.1 Team role permission configuration

Add an AI Permissions section to the team role edit page, including permission templates, daily/monthly token quotas, capability details grouped by category, and risk warnings for high-risk capabilities.

Suggested validation when saving:

• Keep at least Chat capability; otherwise the role cannot use AI sessions.
• Show a risk warning when write capabilities are enabled.
• Administration permissions should not be enabled by ordinary templates unless the user selects Admin Assistant or manually checks them in Custom mode.

7.2 Personal session mode selection

The AI session input area should provide a session permission mode selector: Read-only Mode, Data Mode, Design Mode, and Admin Mode.

When selecting a mode, show this prompt:

The permission mode limits the capabilities AI can use in this session and will not exceed the AI permissions granted to the current role.

7.3 Insufficient permission prompts

When AI attempts an unauthorized action, return a user-friendly prompt instead of exposing low-level errors.

8. Audit and Security

8.1 Audit logs

The following events should be logged: team role AI permission changes, token quota changes, session mode selection, tool calls, data/design reads, high-risk actions, confirmation or cancellation, and permission denial.

Recommended log fields include operator, session ID, app ID, permission mode, permission item, tool or action name, affected object, request summary, execution result, and time.

8.2 External network access control

External network access should be controlled independently. Future extensions may include domain whitelist, domain blacklist, only allowing team-configured MCP services, preventing sensitive fields from being sent to external URLs, and marking external content as untrusted.

8.3 Data and design change protection

High-risk changes should generate a change summary before execution, execute only after user confirmation, record execution results, support affected-scope preview for batch changes, prefer soft delete or recycle bin mechanisms, and show release scope and version information before production publishing.

9. Backend Implementation Suggestions

9.1 Permission check entry point

AI tool calls, app data operations, design operations, and administration operations should all pass through unified permission checks. Recommended check order:

1. Validate user login state and team identity.
2. Read the user's team role AI permissions.
3. Read the current session permission mode.
4. Apply the user's existing business permissions.
5. Check whether the target capability is allowed.
6. Check whether secondary confirmation is required.
7. Record audit logs.

9.2 Capability enum

Enum Value	Name
CHAT	Chat
FILE_UPLOAD	Upload Files
EXTERNAL_NETWORK	Access External Network
DATA_READ	Read Data
DATA_CREATE	Create Data
DATA_UPDATE	Update Data
DATA_DELETE	Delete Data
APP_DESIGN_READ	Read Design
APP_DESIGN_WRITE	Update Design
APP_CREATE	Create App
APP_DELETE	Delete App
APP_PUBLISH	Publish App
APP_MEMBER_MANAGE	Manage App Members
COMPANY_ADMIN	Manage Team

The backend enum is defined in informat-comm/src/main/java/informat/comm/domain/model/AiPermissionAction.java. Frontend display text can remain localized, but requests and logs should keep the backend enum value to avoid permission logic being affected by copy changes.

9.3 Session mode enum

Enum Value	Name
readonly	Read-only Mode
data	Data Mode
design	Design Mode
admin	Admin Mode

9.4 Tool permission mapping

System tools should declare AI permissions according to their actual capabilities. During permission checks, the system uses the permissions declared by the tool to determine whether the current role and session mode allow the call.

Permission Action	Permission Name	Covered Tool Capabilities	Description
CHAT	Chat	Current app switching, AI Q&A, documentation reading, current time retrieval, script calculation, HTML preview, session management, filter condition generation	Basic tools that do not directly modify business data or app structure.
DATA_READ	Read Data	Record query, count query, process/task query, table information query, login information query, app/user query, document reading, search, knowledge base search, Office file reading	Reads business data, workflow tasks, knowledge base content, table definitions, app users, and documents.
DATA_CREATE	Create Data	Batch create records, start processes, create schedules, create tasks	Creates records, process instances, schedules, or tasks.
DATA_UPDATE	Update Data	Batch update records, complete workflow tasks, finish tasks	Updates records and completes workflow or task items.
DATA_DELETE	Delete Data	Batch delete records	Deletes records.
APP_DESIGN_READ	Read Design	Read app definitions, drafts, permissions, tables, scripts, dashboards, BPMN, websites, code, APIs, scheduled tasks, i18n, automation, surveys, and listeners	Reads app design metadata.
APP_DESIGN_WRITE	Update Design	Save app definitions, update app information, roles, permissions, table configuration, scripts, dashboards, BPMN, websites, code, APIs, scheduled tasks, i18n, automation, surveys, AI chat, and listeners	Updates app design metadata.
APP_CREATE	Create App	Create team app	Creates an app.
APP_DELETE	Delete App	No registered tool capability yet	Reserved permission.
APP_MEMBER_MANAGE	Manage App Members	Create, update, and delete app members	Manages app members.
APP_PUBLISH	Publish App	Publish app	Publishes an app.
COMPANY_ADMIN	Manage Team	Manage team members, roles, departments, app groups, expert configuration, AI model lists, system email, and notifications	Manages team-level configuration.
FILE_UPLOAD	Upload Files	Workbench file upload	Uploads session or workbench attachments.
EXTERNAL_NETWORK	Access External Network	Read external web content	Reads external web content.

Maintenance rules:

• New system tools must declare the corresponding permission action.
• If a tool's behavior changes and its risk level changes, update its permission declaration at the same time.
• Delete, publish, member management, and team management tools must be treated as high-risk capabilities and trigger secondary confirmation.
• APP_DELETE is currently reserved. It can be displayed in the documentation and frontend, but only takes effect after backend tools are registered.

10. Typical Scenarios

10.1 Regular member queries data in Read-only Mode

1. The administrator grants Read-only Assistant permissions to the Regular Member role.
2. The user enters an AI session and selects Read-only Mode.
3. The user asks, "What is this month's sales amount?"
4. AI reads data within the user's data permission scope and answers.
5. If the user asks AI to update the sales amount, the system prompts that the current session does not allow data modification.

10.2 Operations user maintains data in Data Mode

1. The administrator grants Data Assistant permissions to the Operations role.
2. The user enters an AI session and selects Data Mode.
3. The user asks AI to change the follow-up status of 20 customer records to Contacted.
4. AI generates a change summary and requests confirmation.
5. After confirmation, AI performs the update and records an audit log.

10.3 Implementation user adjusts an app in Design Mode

1. The administrator grants Design Assistant permissions to the Implementation role.
2. The user enters an AI session and selects Design Mode.
3. The user asks AI to add a Customer Level field to the customer table and adjust the list page display.
4. AI generates a design change summary.
5. After confirmation, AI updates the table structure and page configuration.

10.4 Administrator publishes an app in Admin Mode

1. The administrator role is granted Admin Assistant permissions.
2. The user enters an AI session and selects Admin Mode.
3. The user asks AI to publish the CRM app to production.
4. AI shows the publish scope, version, and risk warning.
5. After confirmation, AI publishes the app and records an audit log.