With the growing popularity of autonomous AI agents, CISOs and IT directors face a critical challenge: how to integrate generative AI capabilities into corporate environments without losing control over operational processes. Business pressure to delegate complex tasks to AI often conflicts with fundamental cybersecurity requirements. Security departments fear that granting agents freedom of action without proper orchestration will turn them into uncontrolled points of failure.
The Excessive Agency phenomenon: why CISOs fear full AI autonomy
The security problem with modern generative AI (GenAI) integrations lies in the architectural approach to agent design. When developers create an AI agent, they often grant it direct access to internal APIs or databases via function calling. In this scheme, the large language model (LLM) decides which action to perform on its own, rather than following a defined business algorithm.
This is where the threat arises, which OWASP experts classify as Excessive Agency—a key risk for GenAI-based applications according to the OWASP Top 10 for LLMs 2025. This risk ranks alongside indirect prompt injections (LLM01:2025) and sensitive information disclosure (LLM02:2025). If an attacker can manipulate the context the agent receives, the model may perform unauthorized actions, such as transferring data to third parties or modifying critical records.
Industry estimates suggest that up to 49% of vulnerabilities in autonomous model deployments are linked to excessive access rights, and about 13% of pilot projects are frozen during the security audit stage due to uncontrolled agent behavior. Secure AI integration into corporate environments is only possible when algorithms act as restricted executors within strictly orchestrated processes.
Architectural barrier: orchestrating AI agents via BPMN 2.0 and DMN
To neutralize the risk of Excessive Agency, it is necessary to prevent the AI agent from independently determining the sequence of process steps. Instead of allowing the model to manage execution logic, it should be embedded into an executable BPMN 2.0 (Business Process Model and Notation) model.
According to Camunda specifications, the BPMN 2.0 standard is executable: the same model simultaneously documents the process and manages its execution at the process engine level. In this architecture, the AI agent is invoked only at a specific step of the process (Service Task) and has access only to the data provided by the engine within the current task context.
The DMN (Decision Model and Notation) standard is used to control decision-making. As noted by the Object Management Group (OMG), DMN allows for the separation of business logic from the process flow by moving it into separate, manageable decision tables. Instead of relying on probabilistic LLM inferences for operational decisions, the system passes data generated by the agent through strict rules.
For example, in a transaction limit verification process, an AI agent can analyze input data and initiate a request. However, the final approval decision is made solely based on a DMN table with rigid business rules, neutralizing the risk of model hallucinations.
The Human-in-the-loop principle: automating routine without losing control
The pursuit of fully autonomous business processes is unjustifiably risky. Managed automation is more effective, where routine operations are performed autonomously, but significant control over final decisions is maintained through the Human-in-the-loop principle.
A typical example is incoming document processing. An AI agent classifies incoming information, retrieves relevant data, and prepares a draft response. However, the final signature or transaction confirmation is performed by an authorized employee via the BPM system.
Role-based security (RBAC) at the process level: limiting AI executor rights
AI agents must adhere to the principle of least privilege. To achieve this, a role-based access control (RBAC) model and row-level security (RLS) are implemented at each node of the BPMN process.
An example of such secure integration is the orchestration of AI agents via the low-code platform Scriptum. Scriptum uses Camunda for business process management and relies on the architectural mechanisms of the UnityBase platform (jointly developed by companies within the Intecracy Group, where InBase is a key developer). The platform uses a unified domain metadata model that inextricably links data, APIs, and security rules.
Thanks to RLS mechanisms and access control lists (ACLs) built into commercial editions of UnityBase, the AI agent's rights are strictly limited. Even in the event of a successful prompt injection attempt, the agent will physically be unable to access database records that do not belong to its current task. Meanwhile, for organizations requiring the development of complex specialized AI solutions, Softengi provides custom development in accordance with the requirements of the international AI management standard ISO 42001.
Audit and monitoring: using process mining to control AI behavior
Even with architectural limitations, AI actions require continuous auditing. Process mining technology is suitable for this. As Celonis explains, process mining allows for the reconstruction of real process flows based on digital footprints (event logs), showing how the process is actually executed rather than how it was modeled.
By analyzing logs, process mining tools compare actual AI agent actions with reference BPMN models, allowing for the immediate detection of deviations, bypassed approval steps, or the emergence of shadow processes. Thanks to the built-in audit trail at the platform level, cybersecurity specialists always have a complete history of every AI agent's operations.
Matrix of responsibility distribution and risk mitigation for AI agents
| Process stage | AI agent role | Security safeguard (BPMN/DMN/RBAC) |
|---|---|---|
| Initiation and data collection | Initial analysis and classification | Restricted database access via Row-Level Security (RLS) |
| Operational decision-making | Proposal generation/calculation | Rigid limits and rules in DMN tables outside the LLM |
| Approval and signing | Document draft preparation | Mandatory Human-in-the-loop step (human verification) |
| Transaction execution | Data transfer to legacy systems | Restricted API keys with minimal access rights (Least Privilege) |
By combining the flexibility of generative models with strict control over executable processes via BPMN 2.0, DMN tables, and a robust infrastructure security layer, companies can scale automation without threatening their digital perimeter.
FAQ
What is Excessive Agency in the context of LLM security and how can it be prevented?
Excessive Agency is a critical risk according to the OWASP classification, where an AI agent is granted overly broad access rights to systems and APIs, independently deciding which actions to perform. This can be prevented by embedding agents into strict executable BPMN processes and applying the principle of least privilege.
How can an AI agent be integrated into a BPMN process without the risk of unauthorized actions?
The AI agent should be invoked exclusively as an executor of a specific service task within the process engine. In this architecture, it gains access only to the limited data context of the current task and cannot independently change the logic of transitions between process stages.
What is the role of the DMN standard in controlling artificial intelligence decisions?
The DMN (Decision Model and Notation) standard allows for the separation of business rules from the process flow and language model logic. Although an AI agent can suggest decision options, final validation—such as limit calculations—is performed based on strictly defined rules in DMN tables, eliminating errors caused by AI "hallucinations."