According to the updated OWASP Top 10 for LLM 2025, the risk of "Excessive Agency" has become a critical threat to enterprise systems. When integrating autonomous AI agents into ECM platforms, we grant the model the authority to act on behalf of a user or system. The problem arises when an agent exceeds its functional duties, performing operations not envisioned by the security architecture.
Why RBAC fails to meet the challenges of autonomous agents
Classic Role-Based Access Control (RBAC) is designed for static user roles. However, AI agents operate directly via API. In such a model, RBAC often becomes a "bottleneck" because it does not account for the context of each individual request. An agent may initiate a sequence of calls that are technically permitted for its assigned role but violate business logic. According to industry estimates, up to 49% of security risks in AI integrations are related to uncontrolled data access due to a lack of contextual request analysis.
Excessive Agency: how LLMs exceed their authority
OWASP identifies Excessive Agency as a distinct class of risks for GenAI applications, where the model performs actions that exceed its purpose. For example, an agent assigned to analyze public reports might, due to a logic error, gain access to confidential HR documents because its technical token has broader access rights. Furthermore, an agent can perform database writes via API, bypassing permission checks if RBAC is configured only at the user session level rather than at the level of a specific entity request.
From static roles to dynamic attribute-level security
An effective solution is the transition to attribute-level security, where each request is validated through domain metadata. The UnityBase platform, upon which solutions such as Megapolis.DocNet and Scriptum are built, implements a security model that allows for data access control regardless of who initiated the request—a human or an AI agent. This allows restricting the agent's access only to the necessary object attributes, minimizing the risk of unauthorized leakage.
Architectural protection methods: sandboxes and auditing
Security must be multi-layered. Using isolated environments (sandboxes) allows for limiting the data visibility scope. Anomaly monitoring is essential: if an agent's activity shows a 13% deviation from standard work patterns, the system should automatically restrict access until an audit is completed. Future operations should be based on threat modeling principles (e.g., using the MITRE ATLAS methodology), which helps identify potential paths for model exploitation.
AI agent security checklist for ECM
- Is the agent's access limited only to the necessary object attributes?
- Does every agent request pass through domain metadata validation?
- Is the agent isolated in an environment with restricted write permissions?
- Is a detailed log of all agent actions maintained for auditing?
- Is an alert system configured for anomalous activity (e.g., a 13% deviation from standard patterns)?
FAQ
Why does RBAC not protect against AI agents?
RBAC is based on static roles, whereas AI agents operate dynamically. They can execute requests that are technically permitted by the role but violate business logic.
What is Excessive Agency in the context of LLMs?
It is a risk where the model performs actions that exceed its intended purpose, gaining access to data or functions not envisioned by the security architecture.
How to implement attribute-level security in an ECM system?
It is necessary to implement metadata validation at the domain level, where each operation is checked for context compliance, rather than just verifying user access rights.