As the autonomy of AI agents grows, their use is shifting from experimentation to real-world automation of corporate business processes. However, AI integration creates a critical threat to enterprise IT security: the risk of "Excessive Agency." According to the OWASP classification (Top 10 Risk & Mitigations for LLMs and Gen AI Apps 2025), this class of threats arises when an intelligent agent is granted overly broad authority, allowing it to perform actions beyond expected behavior.
For technical leaders and architects, this is a serious challenge: how to delegate routine operations to controlled AI agents without granting them unlimited rights to execute critical transactions? The solution lies not in attempting to make the Large Language Model (LLM) "safe" through prompts, but in strictly limiting its agency through deterministic orchestration standards (BPMN) and business rules (DMN).
Anatomy of excessive agency: why AI agents lose control according to OWASP
When developers create an AI agent, they typically provide it with access to a set of APIs and instruct it with a basic prompt. The agent analyzes the request, plans the sequence of actions independently, and decides which interface to call. This autonomy is where the fundamental vulnerability lies. According to the OWASP classification, the risk of Excessive Agency arises from three main factors:
- Over-privileged APIs: The agent has access to API methods that it does not need to perform its immediate task (e.g., the ability to write or delete data instead of just reading it).
- Over-privileged Access: The service account under which the agent operates has excessive permissions within the target system.
- Lack of Verification: The system blindly trusts the output from the LLM without verifying it against business logic.
Consider two real-world examples that illustrate these threats in a corporate environment:
- An AI agent with access to a financial system API attempts to execute a transaction not provided for by the process schema. This can occur due to a successful Prompt Injection attack or a model hallucination.
- An agent makes a decision regarding a customer discount that directly contradicts the DMN decision table, which serves as the company's single source of truth for business rules.
BPMN 2.0 as an external constraint: why orchestration must be deterministic
To eliminate the risk of Excessive Agency, it is necessary to remove the AI agent from the role of process orchestrator. AI should not independently decide which step comes next. This function must be performed by a deterministic workflow engine operating according to the international BPMN 2.0 standard (also published as ISO/IEC 19510:2013).
In such an architecture, the AI agent becomes the executor of a specific, isolated process step. It receives only the data necessary for that task and returns the result in a strictly defined format. The flow, transitions, and system API calls are managed by the BPMN engine. This approach ensures visibility into the state of every process instance and prevents situations where AI skips mandatory approval stages. BPMN does not eliminate the risks of the LLM itself, but it reliably limits the blast radius to a single task.
Separation of duties with DMN: removing arbitrary decision-making from AI
Beyond controlling the process flow, it is important to limit decision-making logic. If an AI agent is tasked with assessing risks or calculating deal parameters, these rules should not be embedded in its system prompt.
The DMN (Decision Model and Notation) standard is used for this purpose. DMN allows business rules to be moved out of code and process flows into separate decision tables. In this scheme, the AI agent performs only a preparatory function: it collects and structures data (e.g., analyzing a complaint or contract) and passes it as input parameters. The final decision is made by a deterministic DMN engine based on strictly fixed rules that the AI cannot alter.
Secure workflow architecture: API isolation and role-based access (RBAC/RLS)
Implementing managed AI agents requires a robust infrastructure platform. For instance, the low-code platform Scriptum (a product from the Intecracy Group technology alliance portfolio) utilizes UnityBase platform mechanisms to control processes. Thanks to this architecture, every agent step is constrained at multiple levels:
- Metadata-level constraints: A unified Domain metadata model defines clear boundaries for the data and APIs the agent can access.
- Role-based access (RBAC): The agent's service account is granted the minimum necessary set of roles.
- Row-level security (RLS): The RLS mechanism limits the agent's data visibility to only those records directly related to the current BPMN process.
For systems with heightened security requirements, the official UnityBase platform website recommends using Enterprise or Defence editions, which add support for extended auditing and additional authentication mechanisms.
Auditing and logging AI agent actions in critical corporate processes
The final line of defense against Excessive Agency is absolute transparency and the ability to perform retrospective analysis. Using an Audit Trail mechanism (specifically the DataHistory module in UnityBase) allows for a full audit of agent actions via event logs for a significant portion of critical transactions. The input prompt, raw LLM output, DMN engine decisions, and specific database changes are all subject to logging. This ensures compliance with regulatory requirements and enables the use of Process Mining tools for early anomaly detection.
Agency control matrix: comparing architectural approaches
| Architectural approach | Excessive Agency risk | Control and limitation mechanism |
|---|---|---|
| Autonomous agent (no BPMN) | Maximum | None. The agent calls APIs and forms the process flow itself. |
| Agent in a rigid BPMN process | Low | The agent performs only one isolated task in the schema; orchestration is handled by the engine. |
| Agent with DMN integration | Minimal | Business rules are fixed in a decision table; AI cannot change them. |
In summary, secure AI integration requires architectural discipline. Instead of attempting to teach an LLM safety rules, IT architects must build a rigid external framework around it using deterministic BPMN 2.0 processes, DMN decision tables, and a strict role-based model at the platform level.
FAQ
How does the BPMN 2.0 standard help prevent the risk of Excessive Agency in LLMs?
BPMN 2.0 takes over the process orchestration function. The AI agent no longer decides which step to take next; it only executes an isolated task within a strictly defined schema where all transitions and API calls are controlled by the process engine.
Can DMN be used to limit an AI agent's financial decisions?
Yes, DMN moves business rules into declarative decision tables. The AI agent only collects data, while the final decision is made by the DMN engine based on fixed rules that the AI cannot change or ignore.
How can AI agent actions be audited in corporate systems?
It is necessary to log all input prompts, LLM responses, DMN decisions, and database changes via a system Audit Trail (e.g., the DataHistory module). This ensures a full audit of agent actions in event logs for security analysis.