The evolution of artificial intelligence has shifted generative models from experimental interfaces to the core of corporate IT infrastructure. According to the Microsoft 2026 Work Trend Index Annual Report (analyzing over 100,000 chats in Microsoft 365 Copilot), 49% of conversations support complex cognitive work: data analysis, decision-making, and evaluation. However, integrating large language models (LLMs) and autonomous AI agents into closed enterprise environments creates significant information security challenges.
Classic perimeter defense tools (firewalls, WAFs) are proving ineffective against new attack vectors because they cannot recognize semantic manipulations in prompts. This leads to unauthorized access to corporate knowledge bases and the execution of destructive actions by AI agents.
Why traditional security perimeters fail against Prompt Injection (LLM01:2025)
In classic web applications, there is a clear architectural boundary between code (instructions) and user data. However, in LLM architecture, this boundary is blurred, leading to the mixing of data and instructions. The model processes system developer commands and user input through a single semantic channel.
An attacker can craft a manipulative query that forces the model to ignore system instructions to extract confidential training data or personal information. According to the OWASP Top 10 Risk & Mitigations for LLMs and Gen AI Apps 2025, Prompt Injection is defined as the number one critical threat (LLM01:2025). Traditional security tools do not detect these attacks because they appear as normal text syntactically. Meanwhile, according to the Cisco AI Readiness Index 2025, only 13% of organizations are classified as Pacesetters in AI readiness, highlighting a market-wide maturity deficit in building architectural AI security.
Anatomy of data leaks: how RAG systems bypass access policies
The most common pattern for LLM integration in the enterprise segment is the Retrieval-Augmented Generation (RAG) architecture. Models connect to vector knowledge bases to retrieve relevant document fragments and generate accurate responses.
This creates a risk of Sensitive Information Disclosure (LLM02:2025). If the search service has full access to the entire repository and access restrictions are managed only via system prompts (e.g., "do not show financial reports to regular users"), data leakage becomes inevitable. Through manipulation, an attacker can force the model to reveal metadata or the content of confidential documents. An additional threat is Indirect Prompt Injection, where a malicious prompt is hidden in an external document, webpage, or email that the agent reads while performing a task.
Architectural approach per NIST AI RMF 1.0: Govern, Map, Measure, Manage
To build a robust defense system, it is necessary to move away from attempting to solve the problem solely at the prompt level. AI system security should be viewed through the NIST AI Risk Management Framework (AI RMF 1.0), which is based on four functions:
- Govern: Establishing an AI security culture, implementing compliance policies, and assigning responsibility for AI solution development.
- Map: Identifying the context of model usage and mapping potential attack vectors at every stage of its lifecycle.
- Measure: Assessing system vulnerability using metrics and utilizing the MITRE ATLAS framework for threat modeling (Adversarial AI).
- Manage: Implementing technical countermeasures to minimize risks in real-time.
Practical steps: from data isolation to AI Red Teaming
Building a secure architecture requires adhering to the principle of least privilege:
- Data layer isolation (RLS/ACL): Database queries must be executed within the initiator's permissions. Applying Row-Level Security (RLS) at the data storage level blocks access to confidential files before they enter the model's context.
- Separation of instructions and data: Using structured query templates (e.g., system and user roles via API) helps the model better differentiate system commands from external input.
- Validation and filtering (Guardrails): Any output stream from the model must pass through automated PII masking systems.
- AI Red Teaming: Regularly simulating attacks on AI agents using the MITRE ATLAS methodology to identify vulnerabilities.
AI infrastructure defense matrix: threats and architectural countermeasures
| Threat (OWASP LLM Top 10) | Attack vector description | Architectural countermeasures |
|---|---|---|
| Prompt Injection (LLM01:2025) | Manipulating input text to bypass model system instructions. | Semantic query analysis, use of structured chat templates via API, strict execution privilege limits for AI agents. |
| Sensitive Information Disclosure (LLM02:2025) | Extracting confidential data through model responses. | Implementing Row-Level Security (RLS) before the vector search stage, masking PII in output streams. |
| Indirect Prompt Injection | Embedding malicious instructions in external data sources (emails, websites). | Validation of external data, isolated sandboxes for parsing unstructured content. |
Developing AI agents without risk: the Softengi and UnityBase approach
Implementing architectural requirements requires mature tools and expertise. Softengi (certified under the ISO/IEC 42001:2023 AI management standard) implements custom AI solutions based on the Security by Design principle. In corporate projects, the UnityBase technology platform from InBase is utilized.
UnityBase is a full-stack JavaScript low-code platform that provides a built-in security model critical for LLM applications. Support for Row-Level Security (RLS), Role-Based Access Control (RBAC), and auditing ensures that any semantic query via the AI interface is processed strictly within the current user's access rights.
Solutions such as Megapolis.DocNet and Scriptum.DMS (with an AI center) are built on the UnityBase platform. Thanks to RLS at the database level, even in the event of a Prompt Injection attempt, the RAG system cannot extract information to which the user does not have legitimate access. AI system security in the enterprise segment is not solved by external filters; it requires data isolation at the architectural level and the use of platforms that ensure strict access control.
FAQ
How can Prompt Injection be prevented in enterprise applications without losing the flexibility of model responses?
It is impossible to completely block Prompt Injection solely at the system prompt level. Protection lies in architectural separation: using API templates (system/user roles), isolating the AI agent's execution environment, and implementing output filtering (Output Guardrails).
Can a standard WAF protect an LLM from confidential data leaks?
No, classic WAFs analyze traffic for known signatures (e.g., SQL injections) but do not understand the semantic context of natural language. Protecting LLMs requires strict access segregation at the data level (RLS/ACL) before data is passed into the model's context window.
How should access rights (ACL/RLS) be configured for a corporate knowledge base in RAG systems?
Configuration should occur at the DBMS level (as implemented in the UnityBase platform), not at the LLM instruction level. The RAG mechanism must first apply document filtering based on user permissions, and only send accessible fragments to the model for response generation.