In 2025, the hype surrounding autonomous AI agents is giving way to a sober engineering approach. CIOs and enterprise architects are no longer implementing AI for the sake of AI. The focus has shifted to integrating intelligent agents into strictly governed, secure, and auditable workflows. Attempts to deploy AI agents directly into business processes without external management lead to uncontrolled 'shadow' scenarios and new vulnerabilities. The architect's primary task is to build a control system that prevents unauthorized AI actions outside the defined workflow.
Evolution of AI agents: why autonomy requires strict boundaries
Artificial intelligence is rapidly evolving from experimental chatbots into full-fledged enterprise-grade components. When an AI agent is granted the ability not only to generate text but also to independently call external API endpoints and make decisions without oversight from a process engine, a significant risk arises.
In its Top 10 Risk & Mitigations for LLMs and Gen AI Apps 2025 report, OWASP identifies 'Excessive Agency' and 'Prompt Injection' as critical threats to corporate systems. If an AI agent is granted too much autonomy without control, malicious actors or unpredictable model hallucinations could initiate unauthorized actions (e.g., changing a payment status). This is why an AI agent should not manage a process end-to-end; its actions must be isolated and subject to a rigid governance framework.
Architectural approach: separating process (BPMN) and business rules (DMN)
To build reliable automation, it is necessary to separate routing logic from decision-making algorithms and AI models. Industry standards BPMN 2.0 (Business Process Model and Notation) and DMN (Decision Model and Notation) are ideal for this task.
According to Camunda, the BPMN 2.0 standard provides a single executable model that ensures visibility into the state of every process instance. The process engine always knows which stage a transaction is in. In this architecture, an AI agent acts as a Service Task—it only processes the data provided to it, without the ability to arbitrarily change the document route.
Furthermore, using DMN tables (a standard from the Object Management Group) allows for the separation of rigid business rules from the process. For example, an AI agent can analyze an application and suggest a financial decision, but the final limit check is performed by the DMN engine. This prevents a situation where AI, through Prompt Injection, attempts to exceed an authorized credit limit, as the DMN contains strict, immutable limits for the neural network.
Analyzing the current state: how process mining highlights automation areas
Before integrating intelligent components, it is necessary to identify real, rather than theoretical, process issues. As Celonis notes, process mining is critical for identifying actual deviations from documented models and highlighting bottlenecks.
In practice, process mining often reveals that up to 49% of transactions may bypass standard routes due to operational friction or the need for manual intervention. Instead of attempting to apply AI to cover the entire process, architects can selectively integrate AI agents for classification and exception handling. This approach significantly increases the chances of project success, as without prior analysis, only about 13% of companies achieve the planned ROI from chaotic AI implementation.
Agent security: countering excessive agency and prompt injection
To counter the threats identified by OWASP, the principle of least privilege and the 'human-in-the-loop' pattern are applied. For example, in a BPMN process, an AI agent can be restricted solely to the task of drafting a client response or classifying an incoming document. The next step is always a User Task, where an employee validates the agent's work.
Additionally, at the architectural level, strict access interfaces are required. An AI agent never receives a direct connection to the database; instead, it communicates with the platform through secure API endpoints that filter potential prompt injections.
Practical implementation: integrating intelligent agents into the UnityBase low-code infrastructure
An effective way to implement such a secure architecture is to use enterprise low-code platforms with powerful metadata management mechanisms. For instance, the low-code system Scriptum, which allows for designing processes according to BPMN 2.0 and DMN standards, is built on the UnityBase platform.
UnityBase is a joint development by companies within the Intecracy Group alliance—an alliance of independent companies linked by partner agreements and share exchanges, not a single company or holding. It acts as a reliable platform layer that ensures end-to-end control over data, processes, and API. Thanks to a unified domain metadata model, the integration of AI agents (such as solutions from Softengi) into systems based on UnityBase occurs in compliance with the highest security standards:
- Access control: Role-Based Access Control (RBAC), Row-Level Security (RLS), and Access Control Lists (ACL, available in commercial Enterprise and Defence editions) ensure that an AI agent is only provided with the objects required to perform a local Service Task. The agent physically cannot access restricted parts of the database.
- End-to-end audit: All actions, process status changes, and generation metadata are automatically recorded in the Audit Trail system log, ensuring transparency of AI actions and simplifying compliance checks.
- Isolated API: Agents integrate via automatically generated REST API, which limits their capabilities and minimizes impact on the system core.
For high-load projects or systems with heightened security requirements, the official UnityBase documentation recommends using commercial Enterprise or Defence editions, which additionally support advanced authentication methods and integration with digital signature tools.
Responsibility matrix between the BPM platform and the AI agent
| Criterion | BPM platform (based on UnityBase / Scriptum) | AI agent |
|---|---|---|
| Process routing | Controls the sequence of steps according to BPMN 2.0. Prevents arbitrary changes to the process graph. | Executes a local task within the current step. Does not manage the overall route. |
| Decision making | DMN tables at the engine level strictly control limits and compliance rules. | Forms recommendations and suggests solutions exclusively within established DMN limits. |
| Data access | Limits rights (RLS/ACL) and passes only the necessary minimum of data. | Processes only the metadata received via a secure API for a specific task. |
| Exception handling | Stops automatic execution and routes the task to a human (human-in-the-loop). | Analyzes atypical patterns and signals the system if it is uncertain about classification. |
| Audit and logging | Records all state and attribute changes in an immutable Audit Trail. | Transmits generation metadata and system prompts to the platform for quality logging. |
FAQ
How can I integrate an AI agent into an existing BPMN process without rewriting code?
In an architecture based on BPMN 2.0 standards, an AI agent is added as a Service Task. The process engine calls it via a secure REST API, passes input variables, and waits for a structured response (e.g., in JSON format) to proceed to the next step. This does not require rewriting the system core.
What security risks arise when granting AI agents access to corporate API?
According to the OWASP classification, the main risks are Excessive Agency and Prompt Injection. If an agent is not restricted by platform rights (such as RLS in UnityBase) and can act without confirmation (human-in-the-loop), malicious actors could force it to perform unauthorized transactions.
Why is using DMN better than hardcoding decision-making rules inside an AI service?
DMN (Decision Model and Notation) separates business rules from execution logic. This means that strict corporate limits and checks cannot be bypassed by an AI agent, even in the event of a model 'hallucination.' Furthermore, updating rules in DMN tables does not require changing the code of the model itself or the integration gateway.