The integration of generative AI (GenAI) into BPM workflows shifts the security perimeter from static user roles to dynamic data context. Traditional Role-Based Access Control (RBAC) remains a foundational layer, but it is no longer sufficient to prevent sensitive information leaks via AI agents. Organizations face a critical challenge: when autonomous algorithms act on behalf of users, they risk gaining excessive access to sensitive data due to overly broad static permissions. This forces enterprise system architects to transition from role-based models to Attribute-Based Access Control (ABAC) and Row-Level Security (RLS).
Why RBAC no longer protects: the challenge of GenAI integration in business processes
The role-based access model (RBAC) has defined access standards for decades. Architecture was built on a simple principle: a user's membership in a specific group (e.g., "Accounting") grants access to a defined set of tables or documents. This approach is effective in deterministic systems, but modern business process orchestration requires greater flexibility.
Today, AI agents are integrated directly into process orchestration to analyze documents and generate responses. If such an agent operates under a generalized role, it inherits access to the entire data set of that role. The problem is that an AI agent operates only on technical permissions and may disclose information that is functionally available to it but should not be shown to a specific user in their current context.
Anatomy of a threat: how AI agents become a data leak point (OWASP LLM02:2025)
According to the OWASP classification, specifically OWASP LLM02:2025 (Sensitive Information Disclosure), unauthorized disclosure of confidential information is a critical risk for applications using generative AI. Leaks often occur through model responses or integrated tools/plugins when there is a lack of granular access control to the data source.
Consider a real-world example: an AI agent processing customer support tickets operates under a general "Support Agent" role. While executing a complex query, it accidentally gains access to internal company financial documents and reveals their content, as these files were not technically protected from the support role. Traditional RBAC is powerless here, as the agent formally acted within the scope of permitted rights.
The solution is to restrict access not only by user position but also by document metadata (e.g., "Confidential" label) and session context (IP address, working hours). If the current context does not meet the security policy, the AI agent should not be able to read the document.
From role-based to attribute-based access: what are ABAC and Row-Level Security (RLS)
Overcoming this vulnerability requires a transition to dynamic Attribute-Based Access Control (ABAC). This approach defines rights in real-time based on a set of attributes of the subject (position, department), the object (document confidentiality level), and the environment (IP address, request time).
The Row-Level Security (RLS) mechanism allows for such control to be implemented directly at the database or ORM layer. Instead of filtering data in the interface, which is easily bypassed via API, RLS modifies queries on the fly. For example, an AI agent will only be able to see data rows related to the current client or region and will physically not gain access to the rest of the array.
Architectural approach: implementing contextual security on the UnityBase platform
In modern enterprise systems, security must be integrated at the platform core level. An example of this architectural approach is the low-code platform UnityBase, a joint development by companies within the Intecracy Group alliance (where InBase acts as a key, but not the only, developer). Solutions such as Megapolis.DocNet and Scriptum.DMS are built on this platform.
UnityBase uses a unified domain metadata model that combines data descriptions, APIs, and security rules. This allows the system to apply RLS mechanisms and Access Control Lists (ACL) directly at the ORM level. When an AI agent accesses data via an automatically generated REST API, the platform restricts the selection based on the session context.
For critical infrastructure objects, as well as the banking and government sectors, which have heightened security requirements, official documentation recommends commercial Enterprise (EE) or Defence (DE) editions. They support attribute-based security, access restrictions based on device digital fingerprints, hardware tokens, and geolocation. Although an OpenUB version exists under the Apache 2.0 license, official terms include disclaimers regarding its use in organizations associated with the Ukrainian public sector.
Deviation control: using Process Mining for process security auditing
Separating business rules from process logic, implemented using the DMN (Decision Model and Notation) standard, allows for updating decision-making policies without changing the workflow itself (e.g., in BPMN 2.0). However, dynamic auditing requires objective control tools.
Process Mining technology uses event logs to identify the actual path of process execution. By analyzing logs, organizations can identify bottlenecks, deviations from standard security models, and unauthorized "shadow" routes of AI agents. This provides a factual basis for continuous compliance and timely blocking of anomalies.
| Comparison criteria | RBAC (Role-Based) | ABAC (Attribute-Based) + RLS |
|---|---|---|
| Decision basis | Static user role/group (e.g., "Accountant") | Dynamic attributes of subject, object, and environment (IP, time, document status) |
| Reaction to AI agents | Blind spot: AI inherits all rights of the role under which it is launched | Contextual filtering: AI sees only data rows permitted in the current request |
| Administration complexity | Low at start, but leads to "role explosion" during scaling | Higher during policy design, but easy to scale via flexible rules |
| Granularity level | Coarse (access to entity/table as a whole) | Fine (access to specific record/row in the database) |
FAQ
Why is traditional RBAC insufficient for the security of processes with integrated AI?
RBAC operates on static roles and does not account for the dynamic context of a request. If an AI agent operates under a broad role, it gains full access to all its data and, through an incorrect or malicious query, may disclose information that should not be available in that context.
How does Row-Level Security (RLS) work in document management and BPM systems?
RLS restricts access to data at the level of individual records in the database. The mechanism automatically modifies queries at the ORM level by adding context filters (e.g., geographic region or document status), which physically prevents AI agents from retrieving unauthorized data.
What security requirements do the Enterprise and Defence editions of the UnityBase platform meet?
Commercial Enterprise and Defence editions extend the platform's capabilities through attribute-based security, Access Control Lists (ACL), authentication via keys, hardware tokens, and geolocation, which are necessary for critical infrastructure and high-load systems.