Implementing AI agents in enterprise document management systems (EDRMS) requires a transition from an experimental approach to rigorous architectural risk management to avoid critical vulnerabilities such as "Excessive Agency." Integrating autonomous models into the EDRMS perimeter creates a risk of uncontrolled access to confidential data and unauthorized actions if the architecture does not restrict model permissions in accordance with existing user security policies. Secure integration of AI agents requires moving away from direct database access in favor of an API-oriented architecture with strict RBAC/RLS access control and sandbox isolation in accordance with the NIST AI RMF methodology.
Evolution from chatbots to AI agents: the risk of Excessive Agency per OWASP 2025
The boundary between classic Q&A chatbots and autonomous AI agents lies in the level of access to system functions. While chatbots generate text based on provided context, agents have autonomy in calling APIs and tools. However, this autonomy creates new attack vectors. OWASP classifies Excessive Agency as a distinct risk for GenAI applications in its 2025 Top 10 list. This is a vulnerability where a model can perform actions that exceed the developer's original intent.
When an AI agent gains uncontrolled access (e.g., a general API token with administrator rights), the system becomes vulnerable. For instance, due to a misinterpretation of a user request or a hidden instruction, an agent could initiate mass document deletion or unauthorized data transfer if the architecture does not restrict its authority.
Anatomy of the threat: how Prompt Injection leads to unauthorized document access
According to the MITRE ATLAS knowledge base, risks to AI systems are not limited to the model itself but encompass data, infrastructure, and integrated services. The most common compromise mechanism remains Prompt Injection, where manipulative instructions force the model to violate established rules.
If an AI agent receives direct access to a data repository without intermediate permission checks, any successful Prompt Injection could lead to devastating consequences. A practical example of such a threat is a situation where an AI agent attempts to access a financial report for which the current user lacks permissions (an attempt to bypass Row-Level Security, RLS). No modern architecture guarantees absolute protection against all types of AI attacks, but granular API-level access control can significantly limit the "blast radius."
NIST AI RMF security framework: four steps to controlled AI in EDRMS
To minimize threats, architects rely on the NIST AI RMF 1.0 (Artificial Intelligence Risk Management Framework). Although this standard is a voluntary framework rather than a mandatory legal document, it effectively structures AI risk management through four functions:
- Govern: Defining responsibilities and policies. AI agents should not be assigned the ability to make ethical or critical business decisions independently without human oversight.
- Map: Identifying the context of model usage and points of interaction between the agent and the EDRMS.
- Measure: Assessing and testing systems for resilience against anomalous requests.
- Manage: Implementing architectural solutions to limit risks.
As noted in the AWS Well-Architected Framework, regular architectural reviews allow these risks to be identified before they become production incidents.
The sandbox architectural pattern: isolating AI agents via RBAC and RLS on the UnityBase platform
The primary architectural rule is that an AI agent must interact with the EDRMS exclusively through a secure API layer that inherits the current user's permissions. This is implemented through an isolated sandbox pattern.
The technological foundation for deploying such an architecture is the low-code platform UnityBase, developed by the companies of Intecracy Group—an alliance of independent companies linked by partner agreements and share exchanges. Thanks to the built-in Role-Based Access Control (RBAC) and Row-Level Security (RLS) mechanisms of the UnityBase platform, an AI agent physically cannot exceed the permissions of the user who initiated the request. The agent's request is executed within the session context, where RLS rules automatically filter the data selection at the platform kernel level before results are passed to the model.
Practical case: integrating the AI Center from InBase and maintaining an end-to-end audit trail
An example of an industrial solution that addresses these risks is the AI Center from InBase (a member of Intecracy Group). This solution integrates into the existing document management perimeter based on UnityBase, ensuring execution environment isolation via middleware.
A critical element of this integration is ensuring accountability. As the Thoughtworks Technology Radar emphasizes, engineering discipline and integration testing are crucial when choosing architectural approaches. For AI agents, this means maintaining an end-to-end audit trail. In solutions based on UnityBase, the audit trail records every API call made by an AI agent: from the user identifier and the tool invoked to the specific LLM that processed the request. This ensures accountability for user actions and enables rapid incident investigation.
On-premises and LLM-agnosticism: why the enterprise segment chooses independence from cloud providers
Transmitting corporate documents via public APIs creates a risk of confidential information disclosure. Therefore, large enterprises prefer architectures that support on-premises deployment.
The AI Center from InBase is built as an LLM-agnostic solution. This allows for the use of local open-source models without transferring data to third parties. Such an approach minimizes information leakage risks and complies with isolation requirements, keeping all document generation and processing within the organization's secure perimeter.
| OWASP Risk | Architectural Solution | Control Mechanism |
|---|---|---|
| Excessive Agency | Limiting agent API token permissions to the current user's access level (impersonation) | UnityBase RBAC/RLS platform |
| Sensitive Information Disclosure | Local (on-premises) LLM model deployment without data transfer to third parties | LLM-agnostic architecture of the InBase AI Center |
| Prompt Injection | Validation and filtering of incoming requests before LLM processing, execution environment isolation | API Gateway and Scriptum middleware |
| Lack of Accountability | Mandatory logging of every tool call and response generation | End-to-end audit trail of the document management system |
FAQ
How can Row-Level Security (RLS) be implemented for an AI agent searching for documents in a corporate database?
Interaction must occur through the platform's secure API layer (e.g., UnityBase). The AI agent does not make direct database queries; instead, its requests are executed within the user's session context, where RLS automatically filters data before results are passed to the language model.
Which NIST AI RMF requirements are critical for AI-enabled document management systems?
NIST AI RMF is not a mandatory legal standard but a voluntary framework. However, the Govern and Manage functions are critical for enterprise systems: strict access control, maintaining end-to-end audit logs of AI actions, and ensuring human-in-the-loop oversight.
Why might standard cloud APIs from public vendors be unsuitable for enterprise EDRMS?
Transmitting confidential information via public cloud services creates risks of sensitive information disclosure. In such cases, it is more appropriate to use an LLM-agnostic architecture with on-premises deployment of models within the organization's secure perimeter.