System and method for protecting applications in digital environments using agents based on large language models
Patent Information
- Application Number
- PCT/ES2025/070167
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-03-26
- Publication Date
- 2026-10-01
Smart Images
Figure ES2025070167_01102026_PF_FP_ABST
Abstract
Description
[0001] SYSTEM AND METHOD FOR PROTECTING APPLICATIONS IN DIGITAL ENVIRONMENTS USING AGENTS BASED ON LARGE-SCALE LANGUAGE MODELS
[0002] DESCRIPTION
[0003] OBJECT OF THE INVENTION
[0004] The present invention falls within the technical field of cybersecurity applied to computer systems, with special emphasis on the security of Web applications and digital environments through the use of Artificial Intelligence (AI).
[0005] In particular, the present invention relates to a method and system of adaptive protection against threats, based on orchestrated intelligent agents that use large-scale language models (LLMs) to monitor, identify and mitigate security risks in real time.
[0006] BACKGROUND OF THE INVENTION
[0007] There is an increasing demand for connectivity and data flows are growing, as is the advanced technical level of cybersecurity threats.
[0008] Intelligent agents are increasingly playing a crucial role in solving all kinds of problems and tasks because they can operate autonomously, collaborate with each other, and leverage specialized skills to achieve complex objectives. By delegating different tasks to multiple agents, it's possible to streamline processes and accelerate decision-making, ensuring that each problem is handled by the most appropriate agent (each specializing in a specific task). Agents reduce the workload of human teams and also allow them to exchange information quickly, learn from results, and adapt to dynamic conditions.
[0009] One state-of-the-art system is CrewAI, which offers a modular, scalable, and orchestrable multi-agent architecture for collaboration among specialized agents, integrating various sources, services, tools, and more. CrewAI is defined as a framework that facilitates the creation and orchestration of specialized autonomous agents, enabling them to collaborate and solve complex tasks in a modular, scalable, and adaptable way using Python code. It also simplifies workflow management and agent orchestration, utilizing libraries that integrate these functionalities and more.
[0010] However, state-of-the-art systems are not specifically designed to respond in real time to complex cybersecurity incidents, nor to automatically adapt to the changing context of attacks without negatively impacting the system architecture or service continuity. Furthermore, while they enable collaboration between agents and workflow management, they do not comprehensively address critical aspects such as continuous system monitoring for emerging threats, automatic and selective response to compromised functions without disrupting the overall operation of the application, the ability to learn from each incident to progressively strengthen defenses, and the simultaneous optimization of operating costs while ensuring compliance with security regulations.These limitations imply that current systems, while useful in terms of core functionality and multi-agent collaboration, are not sufficient to provide effective, adaptive, and autonomous cyber defense against complex and evolving attacks, especially in contexts of high connection demand and large data flows.
[0011] Therefore, the objective technical problem presented is to improve the detection, prevention, and mitigation of advanced attacks in real time in a cybersecurity system operating in dynamic environments with high connection demand and large volumes of data.
[0012] DESCRIPTION OF THE INVENTION
[0013] The present invention addresses the aforementioned problem through a method / system that combines cybersecurity and AI to provide proactive and dynamic security. This system, applicable to all types of applications (especially web applications), is based on several intelligent LLM (Large Scale Language Model) agents working in a coordinated and orchestrated manner in dynamic environments with high connection demands and increasing data flows. This ensures the protection of critical information and, consequently, system integrity. These autonomous agents identify functions within the code, primarily external ones, and can configure authorization controls to allow or prevent their execution. Furthermore, the agents continuously monitor logs and events, enabling the early detection of potential attacks.If an attack or threat is confirmed, a selective kill switch mechanism is executed, temporarily disabling the affected functions without disrupting the rest of the application, thus providing intelligent resilience to security incidents. Once the threat is contained, agents safely reactivate the affected functions, and the system continuously learns and refines its AI models to strengthen its response capabilities against future attacks. All of this is achieved without compromising the privacy of the architecture, always using custom local models.
[0014] In the context of the invention, the term "local" implies that the model runs on a proprietary computing infrastructure, such as local servers, virtualized environments, containers, or internally managed physical devices, without the data being sent to public cloud computing services unless the privacy and confidentiality of said data are guaranteed. The proposed system / method uses multiple local LLM models. A local LLM model is defined as a large-scale language model that is implemented, run, and hosted in a private (or local) digital environment, i.e., "on-premise" or on an infrastructure controlled by the organization, without relying on cloud services.Local LLM models can take various forms, such as an instance deployed on the user's own servers, a container running on their infrastructure, or even an Application Programming Interface (API) connected to an external model, provided that privacy is not compromised and sensitive data is not exposed. Local LLM models can be based on pre-trained architectures (e.g., GPT, BERT, LLaMA, among others) and can be fine-tuned or customized using Retrieval-Augmented Generation (RAG) techniques and internal system information. These local models, which are customized through periodic pipeline retraining, are used by multiple agents to perform analysis, reasoning, and autonomous decision-making.The training pipeline is a structured set of automated processes that enables the preparation, processing, and use of data collected by the system to train, retrain, or fine-tune one or more local LLM models. This pipeline includes, but is not limited to, data collection, curation and preprocessing, noise and duplicate removal, selection of relevant samples, and the execution of fine-tuning techniques based on real security incidents or other relevant information sources processed by the agents (and stored in a system repository and database).
[0015] In the context of the invention, an agent is defined as an autonomous system based on a large language model (LLM) that perceives its environment, processes information, uses tools, and executes actions to achieve a specific goal. Each agent performs a specific function subject to the various alerts and commands it receives from other agents and system administrators.
[0016] The present invention improves the protection of digital infrastructures against cyberattacks by providing an automated response that detects, mitigates, and prevents advanced attacks in real time, minimizing the impact on the operation of the service in the infrastructure while optimizing resources by selectively disabling compromised functions and continuously improving its defense mechanisms.
[0017] One aspect of the invention relates to a system for protecting applications in digital environments using multiple agents based on LLM models, as defined in claim 1. The dependent claims define advantageous embodiments.
[0018] Another aspect of the invention relates to a computer-implemented method, in particular, implemented in a multi-agent system based on LLM models for protecting applications in digital environments, comprising the following steps executed by multiple agents implemented using at least one local LLM model:
[0019] provide information to agents from a vector database using RAG,
[0020] monitor and record security events in a centralized event management module accessible by agents,
[0021] update local LLM models through a training pipeline, using security incident information obtained from a repository and database that stores information processed by multiple agents,
[0022] where agents execute cybersecurity stages in a coordinated manner to protect an application (e.g., web applications) from a digital environment.
[0023] Another aspect of the invention relates to a computer program product comprising instructions that, when the program is executed by a computer, cause it to carry out the method defined above.
[0024] Another aspect of the invention relates to a computer-readable medium comprising instructions that, when executed by the computer, cause it to execute the method defined above.
[0025] The technical advantages of the present invention over the prior art are fundamentally:
[0026] Advanced protection of critical infrastructure, such as telecommunications networks. Early containment capabilities minimize costly disruptions and ensure operational continuity.
[0027] - Automation of real-time detection and response: The autonomous agent-based architecture optimizes the response to security incidents by executing countermeasures instantly and without human intervention. It improves efficiency by integrating multiple AI agents that work in a coordinated, real-time manner, enabling faster threat detection and immediate response through a selective threat mitigation switch (or "kill switch"). The kill switch acts as a selective shutdown mechanism, not completely shutting down the system, but rather producing a controlled and dynamic shutdown that temporarily disables critical functions in a targeted way. This selective disabling of critical functions reduces the window of exposure to attacks, preventing greater damage and minimizing service disruption.
[0028] Enhanced cyber resilience: It offers a higher level of resilience because, upon detecting threats, the system selectively blocks different sections, allowing the rest of the service to continue functioning smoothly. By implementing proactive defense against cyberattacks, the system reduces the likelihood of security breaches, resulting in a better perception of technological robustness.
[0029] Scalability and dynamic adaptability: The solution is designed to operate on large-scale infrastructures, dynamically adjusting to network growth and service expansion. Its modular architecture allows for the agile integration of new agents or adaptation to different programming languages while maintaining the same core functionality. The AI models can be continuously retrained, improving their detection and response capabilities as threats evolve.
[0030] It offers greater flexibility thanks to the use of local or external LLM models depending on privacy needs (also facilitating configuration by using natural language), as well as Retrieval-Augmented Generation (RAG) techniques to provide additional contextual information. Continuous monitoring and real-time event analysis also facilitate compliance with cybersecurity and data protection regulations. Its automated approach reduces exposure to penalties and ensures that the infrastructure meets the security standards required in the telecommunications sector.
[0031] The architecture incorporates a constant feedback loop, where each recorded incident enriches the training of the AI agents. It uses continuous training pipelines, where incident data is analyzed and reused to refine the models, ensuring the constant evolution of detection and prevention capabilities, thus outperforming other static or rule-dependent solutions. This enables adaptive evolution, improving the accuracy of detecting malicious patterns and responding to new attack tactics, thereby optimizing long-term cybersecurity investments.
[0032] Resource optimization and reduced operating costs: Early threat detection and neutralization prevent expenses associated with incident remediation, data loss, and penalties. Furthermore, the selective interruption mechanism allows for blocking specific functions without disconnecting entire services, thus maintaining system operability and profitability.
[0033] These and other advantages can be derived from the description of the invention that is presented in detail below.
[0034] DESCRIPTION OF THE DRAWINGS
[0035] To complement the description being made and in order to help a better understanding of the characteristics of the invention, according to a preferred embodiment thereof, a set of drawings is included as an integral part of said description, in which, for illustrative and non-limiting purposes, the following has been represented:
[0036] Figure 1 shows a local execution flow of the architecture of a system to protect web applications using LLM-based agents, according to a possible embodiment of the invention.
[0037] Figure 2.- Shows an execution flow of the system training pipeline using four agents for protection, according to a possible embodiment of the invention.
[0038] PREFERRED EMBODIMENT OF THE INVENTION A detailed explanation of an example of a preferred embodiment of the object of the present invention is provided below with the help of the figures referred to above.
[0039] A system is proposed that implements an adaptive threat protection method, based on one possible implementation, oriented towards a specific use case: securing web pages. This is not the only possible implementation or deployment environment, provided the source code uses an interpreted language such as Python, Go, Ruby, etc. This implementation is also applicable in environments using any other type of dynamic scripting language.
[0040] Figure 1 shows a possible system architecture based on a plurality of local LLM models (110) from which tasks are executed and processed within a digital environment (1000), either locally or in a private environment to ensure confidentiality, for a plurality of agents (130). In the example, shown in more detail in Figure 2, four agents are provided, whose respective processes (210, 220, 230, 240) are explained in detail later in the description of Figure 2.
[0041] The initial generic components of the system architecture for implementing, in the private or local digital environment (1000) (“on-premise environment”), a multi-agent web application protection solution, as shown in Figure 1, are:
[0042] Local LLM models (110): These are LLM models deployed on-premises, or private LLM models, implemented to preserve confidentiality. For example, one local LLM model (110) is a service or container that offers application programming interfaces (APIs) for querying data. Another example is the use of other API access to cloud models, such as ChatGPT, provided that data privacy is not compromised. Vector databases (120) are used for Retrieval Augmented Generation (RAG) of information from sources such as documents, records, manuals, etc. RAG is a technique that combines information retrieval (typically using vector databases) with text generation, allowing LLMs to access external sources to improve, above all, the accuracy and currency of the information.This provides agents (130) with a query point for additional documentation and context, such as historical records or "logs," documentation of the implemented code, manuals, etc. This improves the accuracy of queries and the actions to be taken.
[0043] - Agents (130): The agents are created and organized using one of the most widely used frameworks, such as CrewAI or HuggingFace's Smolagents. Depending on the selected implementation, the agents (130) are provided with different functionalities and tools.
[0044] The centralized event management module (140) handles historical logs and monitoring, serving as a collection point for events distributed throughout the protected architecture. To facilitate this process and increase processing speed for the agents (130), the centralized event management module (140) consolidates all logs into a single query point.
[0045] Repository and Database (150) for the agents (130) which is i) a mount point where the agents (130) can dump information or files if necessary and also from which to access all types of files (configuration or logs, for example) and i) a centralized database to store information relating to the different actions of the agents (130), configurations, performance logs, etc.
[0046] Training pipeline (160): This pipeline uses the information collected from the different incidents, recorded, for example, in the centralized database (150) of the previous component. It curates the data to clean the collected information and prepares it for further training or fine-tuning of the local LLM models (110). This process requires local computing with one or more graphics processing units (GPUs).
[0047] The entire threat monitoring and detection process performed by the system focuses on the interaction of multiple agents (130). In Figure 2, this process is carried out with only four AI agents and another set of components that work in coordination to efficiently identify, isolate, and neutralize all types of threats.
[0048] The four blocks in Figure 2 represent the stages (210, 220, 230, 240) carried out in a coordinated manner by four agents, which are summarized as follows:
[0049] First stage (210) performed by a first agent, Agent 1: Identifies critical functions that require strict supervision. Uses natural language input and source code analysis with language models. Generates a list of critical points.
[0050] The second stage (220), performed by a second agent, Agent 2, coordinates authorization and manages a selective kill switch for these functions. A kill switch, also known as a threat mitigation switch, is a security mechanism that allows a system to be quickly disabled to prevent damage or unauthorized access. It modifies code to apply security controls or disable risky methods. The third stage (230), performed by a third agent, Agent 3, monitors logs from various layers to detect anomalies or attacks. It sends alerts to the next agent, Agent 4, when suspicious behavior is detected.
[0051] Fourth stage (240) performed by a fourth agent, Agent 4: Receives alerts from the immediately preceding agent, Agent 3. Immediately blocks the critical functions indicated by the previous agent in charge of the selective kill switch, i.e., Agent 2. It only blocks within the scope of the threat to keep the rest of the application operational. The core of the solution is the ability to detect potential attacks in real time and activate the selective kill switch on critical functions, preventing disruptions to the rest of the system. To achieve this, the four agents coordinate to perform stages (210, 220, 230, 240) as described in more detail below.
[0052] Initially, in the first stage (210) of the monitoring and detection process, the first agent, Agent 1, intervenes. This agent is responsible for identifying the application's critical functions that, by their nature, require stricter monitoring or control. These functions are generally associated with external calls (whether to third-party services, remote resources, user interaction, etc.), and the identification process is based on the configuration provided as input, which determines the organization / user to which the local environment belongs. This input is a natural language interaction that generically specifies all the configuration parameters. There is also a selection of levels for both detection and the application of security measures (e.g., low, medium, high).This first agent uses natural language models to review the source code and, after its analysis, outputs a list of points that should be monitored and, if necessary, blocked if a threat is detected.
[0053] Once Agent 1 has identified all the critical functions, Agent 2 takes over in the second stage (220) as the authorization manager or coordinator, responsible for the selective kill switch for these functions. Agent 2 is in charge of applying security controls (such as authorization validations or temporary deactivation of critical application interaction / entry points, such as certain forms, buttons, or HTTP methods that may pose a risk) by modifying the original code to insert these controls.
[0054] Agent 3 is the observer specializing in the detection of anomalies or attacks, operating in the third stage (230) between Agent 2 and Agent 4. Its main function is to analyze the logs (the sequential recording in a file or database of all events affecting the process) and records coming from the different layers of the application, as well as from servers, proxies, databases, and, in general, any information flow that the system is monitoring. This third agent, like the others, is based on LLMs. Since LLM models (110) are trained on a wealth of information, they already have a strong cybersecurity foundation by default, having been trained on thousands of online documents that discuss these issues. Therefore, LLMs can perform the threat detection task. Furthermore, using RAGs or even fine-tuning significantly improves the accuracy of LLMs for this task.Optionally, the LLM may require some external resources and for that uses a framework tool, but the reasoning itself can be done by the LLM.
[0055] The observer agent, Agent 3, is on continuous alert to trigger notifications when it identifies anomalous behavior or an attack pattern. These alerts are immediately sent to the next agent, Agent 4, who then activates the kill switch on the functions that have been marked as critical by Agent 2.
[0056] Finally, in the fourth stage (240), a final agent, Agent 4, configured to receive incident alerts by Agent 3, immediately blocks the critical functions listed by Agent 2. This blocking is limited to the parts of the code considered critical, but within the scope of the threat, so the application remains operational and provides continuity of service for the rest of the users who are working or accessing other functionalities.
[0057] Once the risk situation is resolved, Agent 3 (in a preferred implementation, although any other agent can perform this function) can determine that there are no further indications of an attack and, therefore, Agent 4 is notified that the attack is over so that the functions that were blocked can be securely reactivated. This "return to normal" process also involves reviewing the logs and confirming that all detected points of attack have been closed. In many cases, this confirmation may require a period of observation after containment to ensure that the attacker does not still maintain an access point to the system and cannot attack it again. In Figures 1 and 2, the system includes feedback: all communication and data exchange between the multiple agents (in the example, four). The application is implemented locally or in a private environment (1000) to preserve the confidentiality of the information.On the other hand, the continuous learning derived from each incident, which reinforces the AI models (110) used, allows the pattern detection and accuracy of the agents (130) to progressively improve with each new experience. The models (110) used by each agent are periodically retrained with new information obtained or with external resources that can provide more details about new and future attacks. The intelligence of the agents (130) is also enhanced through the use of RAGs with specific information that needs to be temporarily provided to the agents (130).
[0058] A practical example is protecting an e-commerce application that has a function called `processPayment()` to manage online payments through an external service (for example, a payment gateway or a banking service). The following describes how the entire process works in this use case:
[0059] Agent 1 identifies the critical function: Based on the initial architecture configuration, Agent 1 detects that `processPayment()` makes external calls to a payment gateway and is therefore classified as a critical function. This agent generates a list that includes the `processPayment()` function, indicating that it is potentially subject to blocking if malicious activity is detected.
[0060] Preventive Phase Preparation by Agent 2: Agent 2 receives the list of critical functions (which includes `processPayment()`) from Agent 1. As a preventative measure, Agent 2 can strengthen security. To do this, Agent 2 modifies the code so that authorization checks are executed before the functions. Agent 2 also configures the logic of the kill switch so that, if an alert is received, only the external call to the payment gateway is disabled, without affecting the rest of the application (e.g., the shopping cart, product navigation, etc.). At this stage, no active blocking occurs; instead, Agent 2 configures the mechanism, ready to be activated.Agent 3 Activity Monitoring: While the application continues to operate normally, Agent 3, the observer agent, analyzes in real time the logs from the application, the proxy server, and, if applicable, other components (databases, firewalls, intrusion detection / prevention systems - IDS / IPS, etc.). Through its AI models, local LLM models (110), this Agent 3 looks for anomalous patterns, such as transaction spikes in a very short time interval, massive attempts to use stolen credit cards, IP addresses with a malicious history, or the injection of suspicious parameters into the payment form.In addition, Agent 3 can issue an alert if it detects a threat: for example, if, at a given moment, Agent 3 registers a sudden increase in requests to the processPayment() function, originating from the same IP address or a range of IPs that appears on blacklists or exhibits clearly automated behavior. Agent 3 determines that the event is a candidate for a mass fraud attack or a denial-of-service attempt specifically targeting the payment gateway. After confirming the anomaly, Agent 3 issues an attack alert and sends it to the next agent, Agent 4, via message passing.
[0061] - Activation of the kill switch by Agent 4: When Agent 4 receives an alert generated by Agent 3, it activates its kill switch logic. Knowing that `processPayment()` was marked as a critical function and that it is an external call, it temporarily blocks (or disables) communication with the payment gateway. From the user's (or attacker's) perspective, any attempt to process a payment receives a controlled error response (e.g., a "Payment Service Unavailable" message). Importantly, only this function is blocked, while other sections of the application (product search, shopping cart review, new user registration, etc.) remain operational.
[0062] Monitoring continues: While the kill switch is active, the observer agent, Agent 3, continues analyzing the logs to see if the suspicious traffic persists, intensifies, or stops. The system continues recording all connection attempts to the payment gateway, and this helps generate data for retraining and adjusting the detection rules.
[0063] Threat end and reactivation: Once Agent 3 determines, based on traffic patterns and the absence of new malicious requests, that the threat has diminished or disappeared, it notifies Agent 4. Agent 4 then proceeds to reactivate the processPayment() function. This process may consist of the following phases:
[0064] • Remove the restriction that prevented communication with the payment gateway.
[0065] • Restore normalcy so that legitimate users can process payments again.
[0066] During this final reactivation process, there may be an additional "testing" or "verification" step to ensure that the attack is no longer active, depending on the security policy set in the "input" (initial or entry configuration).
[0067] The described implementation enables the creation of an agile cybersecurity defense that adapts to the ever-evolving complexity of attacks, preventing disruption to the architecture (and therefore the business or service) through continuous monitoring and automated response, thus protecting critical infrastructure and data at all times. Furthermore, it significantly reduces downtime by selectively disabling only the compromised functions (instead of the entire application), while the system learns and strengthens with each incident, optimizing costs and ensuring compliance with security regulations for more stable and reliable operations.
[0068] An alternative implementation incorporates a real-time vulnerability scanning system integrated with the logs and monitoring module, the broader centralized event management module (140) in Figure 1. This system can be used specifically to detect insecure or zero-day configurations in the source code and can be integrated into the normal flow of agents (130) to provide broader monitoring of the entire adaptive protection system architecture. Upon detecting a suspicious parameter in the digital environment (1000), such as a mismatch in permission policies or an outdated dependency, the system triggers a chain of broader automatic remediation actions, such as suggesting security patches, thereby reducing the window of exposure and increasing the overall resilience of the protected application.In addition, container technologies or isolated testing environments (“sandboxing”) can be used to run parallel copies of the system in order to apply and verify fixes without interrupting the main service.
Claims
1. CLAIMS 1. A system for protecting applications in digital environments (1000), characterized in that it comprises: a plurality of large-scale language models, LLMs, local (110), configured to operate in a digital environment (1000), a plurality of agents (130), each implemented by means of at least one local LLM model (110) and configured to execute a cybersecurity stage, a vector database (120) configured to provide retrieval-enhanced generation, RAG, of information for the plurality of agents (130), a centralized event management module (140) configured to record and monitor security events queryable by multiple agents (130), a repository and database (150) configured to store information processed by the plurality of agents (130), and a training pipeline (160) configured to update local LLM models (110) with security incident information obtained from the repository and database (150), where the agents (130) are configured to coordinate within the digital environment (1000) in the execution of each stage of cybersecurity to protect an application of the digital environment (1000).
2. The system according to claim 1, characterized in that the plurality of agents (130) comprises four agents configured to coordinate in the execution of the following cybersecurity stages: a first stage (210) where a first agent is configured to identify critical functions in the application and generate a list of critical points associated with each critical function identified, a second stage (220) where a second agent is configured to receive the list generated by the first agent and furthermore the second agent is configured to modify the application's source code by inserting security controls for each critical point and configuring a threat mitigation switch for each identified critical function, a third stage (230) where a third agent, communicating with the second agent, is configured to detect anomalies and attack patterns, while the digital environment application (1000) is running according to the code modified with the security controls, and generate alerts if there is an anomaly or attack pattern detected that affects at least one critical point from the list of critical points, a fourth stage (240) where a fourth agent is configured to receive alerts generated by the third agent (230) and selectively block only the critical function associated with the critical point affected by the threat mitigation switch configured for the associated critical function.
3. The system according to claim 2, characterized in that the first agent is configured to identify critical functions from an interaction with the first agent in natural language which is an input where at least all the configuration parameters of the application are indicated and the first agent is configured to generate the list of critical points based on the input.
4. The system according to claim 3, characterized in that the first agent is configured to analyze the application source code using local LLM models (110) and detect critical points in the analyzed source code based on the input.
5. The system according to claim 4, characterized in that the second agent is configured to insert security controls into the source code comprising authorization validations, access restrictions, or temporary deactivation of points of interaction with the application, and wherein the security controls enable or disable the execution of the critical function based on the configuration parameters indicated in the input.
6. The system according to any of claims 2-5, characterized in that the third agent is configured to detect anomalies and attack patterns from an analysis of historical records logged in the centralized event management module (140) and using local LLM models (110) combined with recovery augmented generation, RAG.
7. The system according to any of claims 2-6, characterized in that the fourth agent is configured to, if it receives an end-of-attack notification, reactivate the locked-up critical function.
8. The system according to any of the preceding claims, characterized in that the training pipeline (160) is configured to clean the information obtained from the repository and database (150) by means of data curation and to perform fine-tuning of the local LLM models (110) using the cleaned information.
9. The system according to any of the preceding claims, characterized in that the training pipeline (160) is implemented in one or more graphics processing units located in the digital environment (1000).
10. A computer-implemented method for protecting applications in digital environments (1000), characterized in that it comprises the following steps executed by a plurality of agents (130) implemented by means of at least one local large-scale language model (LLM) (110): provide information from a vector database (120) by recovery-enhanced generation, RAG, to the plurality of agents (130), monitor and record security events in a centralized event management module (140), accessible to multiple agents (130), update local LLM models (110) via a training pipeline (160), using security incident information obtained from a repository and database (150) that stores information processed by multiple agents (130), execute by the plurality of agents (130) cybersecurity stages to protect an application of the digital environment (1000), where each agent executes at least one cybersecurity stage coordinated with the rest of the plurality of agents (130) within the digital environment (1000).
11. The method according to claim 10, characterized in that the cybersecurity stages are executed in a coordinated manner by four agents (130) and are: a first stage (210) where a first agent is configured to identify critical functions in the application and generate a list of critical points associated with each critical function identified, a second stage (220) where a second agent is configured to receive the list generated by the first agent and furthermore the second agent is configured to modify the application source code by inserting security controls for each critical point and configuring a threat mitigation switch for each identified critical function, a third stage (230) where a third agent, communicating with the second agent, is configured to detect anomalies and attack patterns, while the digital environment application (1000) is running according to the code modified with the security controls, and generate alerts if there is an anomaly or attack pattern detected that affects at least one critical point from the list of critical points, a fourth stage (240) where a fourth agent is configured to receive alerts generated by the third agent (230) and selectively block only the critical function associated with the critical point affected by the threat mitigation switch configured for the associated critical function.
12. The method according to claim 11, characterized in that identifying the critical functions by the first agent is executed from an interaction with the first agent in natural language which is an input where at least all the configuration parameters of the application are indicated and the list of critical points generated by the first agent is based on the input.
13. The method according to claim 12, characterized in that it further comprises analyzing the application source code by the first agent using local LLM models (110) and detecting critical points in the analyzed source code based on the input.
14. The method according to claim 13, characterized in that inserting security controls into the source code by the second agent comprises inserting authorization validations, access restrictions, or temporary deactivation of points of interaction with the application, and wherein the security controls enable or disable the execution of the critical function based on the configuration parameters indicated in the input.
15. The method according to any of claims 11-14, characterized in that detecting anomalies and attack patterns by the third agent is executed from an analysis of historical records logged in the centralized event management module (140) and using local LLM models (110) combined with recovery augmented generation, RAG.
16. The method according to any of claims 11-15, characterized in that it further comprises reactivating the critical function blocked by the fourth agent if it receives an end-of-attack notification from any of the other plurality of agents (130).
17. The method according to any of claims 10-16, characterized in that updating the local LLM models (110) by means of the training pipeline (160) comprises cleaning the information obtained from the repository and database (150) by means of data curation and fine-tuning the local LLM models (110) using the cleaned information.
18. The method according to any of claims 10-17, characterized in that the update by means of the training pipeline (160) of the local LLM models (110) is executed in one or more graphics processing units located in the digital environment (1000).
19. A computer program product comprising instructions that, when the program is executed by a computer, cause the computer to carry out the method of claims 1-18.
20. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to carry out the method of claims 1-18.