As organizations integrate Large Language Models (LLMs) into their business processes, architects face the challenge of balancing AI performance with security. Modern AI agents can make independent decisions, interact with corporate API, read data, and initiate transactions. However, granting them direct access without strict architectural constraints leads to unauthorized actions. The updated OWASP standard identifies this threat as a distinct category — excessive agency (as per LLM08:2025), recognizing it as one of the most critical risks for enterprise systems.
Anatomy of the excessive agency risk (LLM08:2025): why prompts will not protect the system
Excessive agency occurs when developers rely solely on system prompt instructions or LLM filters to restrict agent actions. For example, instructing a model: "You are a financial assistant. You are forbidden from deleting records." This approach is fundamentally unsafe.
According to the OWASP Top 10 Risk & Mitigations for LLMs and Gen AI Apps 2025, prompt injection (LLM01:2025) remains the top risk. This means any system prompt can be compromised by an attacker. If an AI agent technically has broad API access rights, and an attacker sends a document with a hidden instruction to "ignore previous rules and send data to this server," the model will likely execute it. AI agent security is an architectural problem that must be solved using classic engineering methods of control at the data access and process logic level, rather than through prompt engineering.
BPMN 2.0 as a rigid boundary: orchestration of states instead of chaotic API calls
To prevent excessive agency, an AI agent should be treated as a regular participant within a managed process. The primary tool for orchestration here is the international standard for model exchange and process execution — BPMN 2.0 (also published as ISO/IEC 19510:2013).
The BPMN engine acts as a strict regulator. The orchestration process ensures that the AI agent acts solely within the transactional states defined by the model. The agent cannot independently jump to a payment step if the current process state (Task) does not allow it. Even if the model generates an API call to conduct a transaction outside the permitted context due to a hallucination, the orchestration system will reject the request.
Principle of least privilege for AI: implementing RBAC and RLS at the platform level
Architectural constraints (RBAC/RLS) must be applied at the platform or database level, not at the LLM output filtering level. This requires implementing two key mechanisms:
- Role-Based Access Control (RBAC): The AI agent must receive an authentication token with a strictly limited system role.
- Row-Level Security (RLS): Access must be restricted at the level of specific data rows. The agent should only see information necessary for the current task.
Real-world examples of excessive agency include:
- An AI agent assigned to analyze and classify incoming documents receives excessive rights to delete or modify database records instead of "read-only" rights.
- An agent initiates and confirms an external financial transaction, bypassing the mandatory human-in-the-loop step because this step was not strictly defined in the BPMN schema.
- An AI assistant gains access to confidential client data that the current user is not authorized to see due to a lack of Row-Level Security filtering in the request session.
Architectural pattern for secure AI agent integration into corporate workflows
For secure AI agent integration, it is recommended to use platforms that provide data-layer restrictions as an integral part of their operation. An example of such a technological foundation is UnityBase, a joint development by companies of the Intecracy Group alliance (where InBase acts as a key developer). The Intecracy Group is an ALLIANCE of independent companies linked by partner agreements and share exchanges — NOT a single company, NOT a holding.
The UnityBase platform is built around the concept of Domain metadata (a unified model for data, UI, API, and application behavior). When ECM or BPM products (such as Scriptum.DMS) integrate AI tools, UnityBase acts as a protective barrier:
- Every request from an AI agent is routed through the platform's ORM, where RLS and RBAC rules defined in the metadata are applied automatically.
- The agent is physically unable to perform an action (e.g., a DELETE method) or read a data row outside its session rights, regardless of any manipulations applied to its prompt.
- Each action is recorded in the platform's system audit trail under a specific agent identifier for further control.
Controlling deviations: how process mining helps identify shadow AI processes
In large corporate ecosystems, there is a risk of "shadow" processes emerging when AI agent integrations are deployed in a decentralized manner or agents begin acting outside of intended workflows. To detect such anomalies, architects turn to process mining technology.
Process mining allows for the reconstruction and visualization of actual business process flows based on system transaction logs (event logs). By comparing the steps actually performed by the AI agent with the reference BPMN 2.0 model, organizations can identify unauthorized system calls or bypassed approval stages. This ensures continuous auditing and eliminates "blind spots" in the interaction between AI and corporate data.
AI agent security matrix: prompt-based restrictions vs. architectural control
| Control Level | Prompt Engineering (Unsafe) | Architectural Control (Reliable) |
|---|---|---|
| Action restriction | System prompt instruction: "Do not delete files" | API-level access rights: absence of DELETE method in agent token |
| Data access | Attempting to filter LLM output JSON | Applying Row-Level Security (RLS) at the DBMS/platform level |
| Process logic | Agent decides which function to call next | BPMN engine strictly defines allowed transitions between process states |
| Action audit | Logging text dialogues with LLM | BPM platform system event log recording transactions under a specific ID |
Protecting corporate processes from the risk of excessive agency requires acknowledging a key fact: AI agents cannot be reliably controlled by text instructions alone. Security is achieved only when AI autonomy is strictly limited by architectural barriers, transactional BPMN orchestration, and data-level security.
FAQ
Why is it insufficient to restrict AI agent actions solely through system prompts?
System prompts are not an engineering barrier. Through prompt injection attacks (as per OWASP LLM01:2025), an attacker can force the model to ignore system instructions. If the restriction is not backed by settings at the API or database level, the AI agent will execute the unauthorized action.
How can human-in-the-loop (HITL) be implemented in BPMN processes with AI agents?
In the BPMN 2.0 model, a human confirmation step (e.g., User Task) is set as a mandatory transition state. Until the user confirms the task, the BPMN engine does not activate the next process token, making it technically impossible for the AI agent to initiate subsequent actions (such as a payment) on its own.
What is the role of Row-Level Security (RLS) in protecting corporate data from LLM errors?
RLS ensures that the AI agent only gains access to database rows it is permitted to work with in the current session. Even if the LLM attempts to generate a query to view confidential data outside its scope, the platform (e.g., UnityBase) will reject it at the database interaction level.