[AI Employee Question] Mechanism for Managing Permissions of AI Employees in NocoBase 2.0+

English Forum
1

Hello NocoBase community,

I am highly impressed with the AI Employee feature introduced in version 2.0. This feature is a game-changer for automating many business tasks.

However, I have a few questions regarding the Permission Management for these AI Employees:

  1. Under which Role does an AI Employee operate?
  • Are AI Employees assigned a specific Role in the system, similar to a regular user (e.g., Administrator, Guest, or a custom AI Assistant Role)?
  • If so, what is the mechanism for assigning or changing this Role?
  1. Fine-Grained Permission Enforcement:
  • Are the Row-Level Security and Field-Level Security rules, which NocoBase is known for, fully enforced on the actions taken by an AI Employee?
  • For example: If an AI Employee is allowed to edit the Orders table but is explicitly forbidden from viewing the Customer_SSN field, will the AI adhere to this rule when performing its tasks?
  1. Preventing Unintended Actions:
  • Are there built-in measures or best practices to constrain the AI Employee’s behavior strictly within the scope of its assigned Skills/Functions, preventing them from executing actions that exceed their granted permissions or fall outside the intended business workflow?

I look forward to insights from the development team or anyone who has experience configuring and using the AI Employee feature.

Thank you!

3

Hello! Glad you like the AI Employee feature. Here’s a quick rundown on how permissions work right now:

1. Whose role does it use?

The AI works as your Copilot , not a separate user. It simply borrows your current identity and role . So, if you are an Admin, it acts as an Admin; if you are a Guest, it acts as a Guest.

2. Are permissions enforced?

Yes, absolutely. Since the AI acts on your behalf, it follows all your existing permission rules.

  • Row & Field Security : If you can’t see the Customer_SSN field, the AI can’t see it either.
  • Action Limits : If you don’t have permission to delete records, the AI won’t be able to do it for you.

3. How to limit it further?

Besides system permissions, you can constrain the AI in two ways:

  • Skills (Tools) : Just don’t give it the tools it shouldn’t use. For example, if you only give it “Query” skills, it physically cannot edit or delete anything.
  • Prompts : You can tell it in the system prompt: “You are a read-only assistant, do not modify data.”

Hope this clears things up! We’re always looking to improve, so keep the feedback coming.

4

Critical Permission Loophole Identified: AI Workflow Bypassing Table Security

Hello, thank you for raising this crucial point. This is an excellent catch and highlights a potential flaw in how permission inheritance interacts with the Workflow/Skill Layer.

We need to treat this as a high-priority security vulnerability, as it contradicts the core principle that the AI (Copilot) must strictly adhere to the user’s explicit permissions.

1. The Core Problem Identified

The issue you describe—where a user lacks direct READ access to the lead table but can successfully use an AI Workflow Skill to QUERY and even CREATE data in that same table—indicates that the Workflow/Skill execution environment is not fully inheriting or enforcing the user’s explicit Row & Table Level Permissions.

2. Why This is Happening (Hypothesis)

The problem likely lies in how the Workflow skill is authorized:

  • Elevated Skill Permissions: The Workflow skill itself might be executing with system-level privileges or credentials that are separate from the requesting user’s identity.
  • API/Workflow Authorization: If the Workflow skill calls an internal API to query/create data, that API endpoint might be configured to bypass the standard user-level permission checks (e.g., using a service account or an administrative token).

3. Immediate Recommendation & Next Steps

This bypass needs immediate investigation and rectification.

  • Verify Skill Execution Context: We must ensure that the Workflow skill (or any related tool) is explicitly tied to and executes under the requesting user’s identity. The skill should fail if the user’s ID lacks READ/WRITE access to the lead table.
  • Enforce Permissions on API Endpoints: Any backend API called by the Workflow must be updated to validate the end-user’s permissions before executing the query or creation command.
  • Restrict Skill Access: As a temporary mitigation, remove the Workflow skill from all users who do not have explicit permissions to access the underlying lead table.

We appreciate this detailed feedback. We are treating this as a serious matter and will provide an update once the root cause in the Workflow permission chain has been fixed.

5

Hello,

Thank you very much for your in-depth exploration and detailed feedback regarding the AI Employee features in NocoBase 2.0. The challenge you raised—restricting AI workflow invocation and managing permissions in multi-user environments—is a critical one as we integrate AI deeper into business logic.

Currently, the NocoBase Workflow engine is designed primarily as a system-level automation tool, meaning its execution logic does not yet fully incorporate the “requesting user” as a permission dimension. Based on your feedback, we have conducted a technical evaluation, and here is our planned direction for improvement:

1. Short-term Recommendations (Workarounds)

In the current architecture, if you need to implement permission-like boundaries, we suggest the following:

  • Configuration Isolation: Assign different AI Employee instances to different roles. For roles with lower clearance, you can disable the workflow-caller skill for their specific AI Employee configuration.
  • In-Workflow Logic Validation: We are looking into enhancing the workflow trigger to pass the Current User/Role Context. This would allow you to manually add a “Condition” or “Query” node at the start of your workflow to verify if the initiating user has the necessary permissions.

2. Long-term Architecture Evolution

To fundamentally resolve the issue of permission synchronization, we are planning to refine how AI interacts with the system:

  • Transition to Action-Based Events: We plan to shift toward having AI tools invoke specific “Data Action” events (e.g., Pre-action/Post-action triggers). The advantage here is that the workflow will automatically inherit NocoBase’s existing Access Control List (ACL), ensuring that AI actions stay strictly within the user’s authorized boundaries.
  • Enhanced Custom Action Permissions: We are considering on strengthening the permission control for custom action events, which could also be added to be called by AI chat. This will ensure that when an AI performs a task on behalf of a user, the security context is consistent throughout the entire process.

We highly value the security and reliability of our AI plugins in complex scenarios, and your input provides a vital reference for our development. These architectural adjustments will be integrated into our roadmap and released in future updates.

Thanks again for your detailed analysis and technical insights! Please feel free to share any further thoughts.