Process Automation 6 min read

Managing AI risks in enterprise BPMN processes

Protecting enterprise workflows from excessive AI agency using domain model architectural constraints to turn AI agents into controlled, auditable nodes.

With the release of the updated OWASP Top 10 for LLMs 2025 vulnerability list and the establishment of the NIST AI RMF 1.0 methodological framework, the enterprise sector faces a fundamental paradigm shift. The era of perceiving artificial intelligence as an autonomous "black box" to which business tasks are delegated without strict boundaries is officially ending. In enterprise architecture, AI must be treated strictly as a controlled, limited, and fully auditable node within standard business processes (BPMN).

According to research on AI readiness, only 13% of organizations are classified as Pacesetters capable of systematically managing such risks. For the remaining companies, integrating large language models (LLMs) into transactional chains often creates additional vulnerabilities. The main challenge for IT architects and CISOs lies in physically keeping AI agents within the scope of their business authority.

Anatomy of the excessive agency threat: why AI agents lose control in workflows

In classic process automation, every step of an algorithm is deterministic. However, when adding an AI agent, developers sometimes grant it excessive autonomy. In the OWASP classification, this risk is defined as Excessive Agency. It occurs when a model is given direct, uncontrolled access to system APIs or databases without strict validation of input and output streams.

A typical threat scenario looks like this: an AI agent receives a task to analyze a customer request. Having broad access to the billing system API, the agent, due to ambiguous instructions or a targeted Prompt Injection attack, may initiate an operation that exceeds its authority or cause a Sensitive Information Disclosure. The problem lies in an architectural flaw: granting AI the authority to execute transactions without intermediate technical and DMN barriers.

Mapping risks according to NIST AI RMF: from chaos to controlled BPMN nodes

The NIST AI RMF 1.0 methodology is not automated software; it is a conceptual framework that proposes structuring risk management around four key functions. When implementing this framework, engineers must transform these functions into specific architectural constraints:

  • Govern: Creating policies where the AI agent is treated as a system user with the minimum necessary access rights.
  • Map: Moving away from abstract roles. AI becomes a specific step (Service Task) in BPMN 2.0 notation, the boundaries of which are strictly regulated by input and output schemas (JSON Schema).
  • Measure: Introducing metrics for assessing compliance with business rules (Model Alignment) based on system log analysis.
  • Manage: Applying active controls and mandatory output filtering.

Architectural template for a secure AI node: Service Task, DMN validation, and human-in-the-loop

To neutralize Excessive Agency, the AI integration architecture must rely on three levels of protection: execution isolation, logical validation, and human control.

The first level is representing the AI agent as a Service Task in a BPMN diagram. The agent does not define the process route independently. It receives a typed request, performs calculations, and returns the result. Attempts by the model to generate data outside the defined schema are blocked.

The second level is DMN (Decision Model and Notation). Before the result from the AI reaches the next step (e.g., ERP), it passes through a deterministic decision table. If the model generates a value that exceeds DMN rules (e.g., exceeding a discount limit), the process is automatically redirected for verification.

The third level is Human-in-the-loop. For high-risk operations, the process does not execute the transaction automatically but creates a User Task for a responsible employee to verify the generated decision.

Access control at the domain model level: how UnityBase mechanisms limit AI

Implementing such an architecture requires a platform capable of ensuring access control directly at the data and API level. One example is the low-code process automation platform Scriptum (a product of Scriptum, a company within the Intecracy Group, which is an alliance of independent companies linked by partner agreements and share exchanges). It is built on the UnityBase platform, a joint development by companies within the Intecracy Group.

Because UnityBase uses a unified domain metadata model that combines data descriptions, access rights, and behavioral logic, developers can strictly limit the rights of AI agents. The platform supports Role-Based Access Control (RBAC) mechanisms, and in commercial editions, Row-Level Security (RLS) and Access Control Lists (ACL).

When an AI agent connects to the system, it interacts with data exclusively through the platform's DBMS-agnostic ORM. Even in the event of a successful prompt manipulation, any attempt to access unauthorized records is blocked at the RLS/ACL level. Security is ensured not only by prompt engineering but by the physical impossibility of exceeding the permissions defined in the domain model.

Audit and monitoring: detecting shadow processes using process mining

Even with restrictions in place, there is a risk of shadow routes where an AI agent provokes unpredictable deviations from the reference workflow. To detect these, the Process Mining methodology is applied.

By analyzing system events (Event Logs), Process Mining tools compare actual process execution with the approved BPMN model. This allows for the identification of anomalies where AI may have bypassed compliance checks. For such analysis to be reliable, every action must be recorded in an immutable log. The UnityBase platform, for example, uses built-in logging and data history subsystems (DataHistory), which form a comprehensive Audit Trail for incident investigation.

AI orchestration risk control matrix (NIST AI RMF vs OWASP LLM 2025)
NIST FunctionOWASP RiskTechnical Mitigation
MapExcessive AgencyDefining the AI agent as a Service Task in BPMN with a limited input/output contract (JSON Schema).
GovernSensitive Information DisclosureImplementing RBAC and Row-Level Security (RLS) at the platform domain model level, limiting AI access to the database.
MeasureModel Alignment FailureContinuous auditing of Event Logs and comparison of actual routes with the reference BPMN diagram.
ManageUnbounded ExecutionMandatory Human-in-the-loop (User Task) step for operations exceeding compliance limits.

Successful process automation using artificial intelligence requires abandoning the illusion of complete model autonomy. Only by integrating AI as a controlled executor within verified BPMN models, protected at the enterprise platform's metamodel level, can innovation be scaled without the threat of losing control.

FAQ

How does NIST AI RMF help protect business processes from LLM errors?

NIST AI RMF provides a methodological framework for structuring risks. Through the Map and Manage functions, developers integrate LLMs not as autonomous systems, but as strictly limited nodes (Service Tasks) in BPMN diagrams, where each step is validated by business rules (DMN) and domain security frameworks.

What is Excessive Agency in the context of BPMN and how can it be prevented?

Excessive Agency is a risk where an AI agent performs actions beyond its authority due to excessive API access. This can be prevented through strict typing of input and output data (JSON Schema), the use of DMN tables, and mandatory Human-in-the-loop steps for critical transactions.

How can secure data exchange be configured between an AI agent and corporate systems?

Secure exchange should be configured through the domain metadata layer of the automation platform. The AI agent accesses the API only via a service account with minimal privileges. Database queries are further restricted by Row-Level Security (RLS) and ACL mechanisms.

Data sources