LightGuardAgents: Secure and Robust Embedded Agents for Internet of Things Devices

Abstract

This paper presents a novel architecture for creating light agents embedded on Internet of Things (IoT) devices, specifically addressing challenges such as security, scalability, and adaptability. Despite the increasing adoption of agent-based approaches in IoT systems, security and robustness mechanisms are often treated as external or ad hoc components in many existing solutions. This limits their effectiveness in dynamic environments that transmit sensitive and personal data and are, by nature, potentially untrusted. The proposed architecture applies Pyro4 for efficient communication among agents and implements a multi-level security scheme that combines symmetric, asymmetric, and hybrid encryption with Time-Based One-Time Passwords (TOTP)-based authentication. This ensures the data confidentiality and integrity within dynamic IoT environments. A case study validates the “agent of things” concept by confirming key security mechanisms such as agent authentication, multi-factor access control, secure communication, and fault resilience. Qualitative testing proved the architecture effective in mitigating common vulnerabilities in distributed agent environments, achieving high reliability scores in terms of security and performance. Experimental results show that over 75% of agent operations were completed in under 2 milliseconds, with a success rate above 99%, confirming the architecture’s lightweight execution and real-time readiness of the architecture for IoT environments. Therefore, the proposed architecture is particularly useful for researchers and practitioners working on secure IoT systems, embedded multi-agent architectures, and intelligent edge computing environments.

1. Introduction

In the current era of the Internet of Things (IoT), the need for distributed systems that enable dynamic, autonomous and smart interaction between devices is more critical than ever. Intelligent software agents are entities that empower IoT devices to enhance machine-to-machine (M2M) communication capabilities and acquire the ability to interact autonomously and intelligently [1]. Agents, organized through agent networks, form multi-agent systems (MAS) [2]. MASs require special attention to ensure secure communication and collaboration while mitigating potential attacks on agents. Moreover, due to the increasingly complex security landscape and heightened security demands, agents must collaborate efficiently, prioritizing the protection of data security and privacy as it is shared and transmitted across the agent network [3].

Current works published in this field reveal remarkable progress in the design of architectures for autonomous and intelligent systems, [4,5]. However, despite these advances, the area of agents still faces common challenges in domains such as data security [6], resource management efficiency [7], and flexibility and adaptability in practical implementation. There is a clear emphasis on the need for technological tools that facilitate the development of agent systems, enabling the advancement of agents in general and, more specifically, the development of embedded agents in IoT devices [8] that are both secure and reliable. This would reduce the likelihood of negative impacts on IoT networks, such as system failure, secrets disclosure, configuration change, consensus delay, or performance degradation [9].

In the context of embedded agents in IoT devices, several proposals have been developed. For instance, Hoose et al. [10] introduced a framework called “beehave,” an innovative approach to MAS designed for integration with Robot Operating System (ROS) and Python 3. This framework aims to implement decentralized behaviors in agents operating within robotic systems. Similarly, Silva et al. [7] proposed a cognitive agent architecture developed using Jason BDI (Believes, Desires, Intentions) and ROS (version 1.7). Their approach was designed to be embedded in platforms like Raspberry Pi 3, optimizing decision-making processes and task management in dynamic environments, ultimately creating a multi-robot system with heterogeneous agents. Likewise, Karaduman [11] integrated rational agents of BDI type on embedded hardware to control Cyber–Physical Systems (CPS), achieving high-level reasoning within a single platform. This proposal was later enhanced by deploying BDI agents integrated with a fuzzy reasoning model for handling imprecise information, significantly improving process control [12].

From an applied perspective focused on solving real-world cases involving IoT technologies, Jiménez et al. [13,14] modeled the behavior of intelligent agents integrated into IoT systems to enhance the performance of automated irrigation systems. The key innovation in these approaches lies in incorporating the reasoning and proactive capabilities of agents into embedded platforms, aligning with the concept of “agents-of-things.”

In another application domain, traffic management, Kouah et al. [15] proposed a system leveraging the agent-of-things concept to monitor multiple smart street lighting units. This system directly connects to IoT devices, acquiring data from various sensors. The agents utilized a fuzzy logic-based reasoning mechanism to improve human security, reduce CO₂ emissions and light pollution, and optimize energy consumption. Similarly, Pantoja et al. [16] presented an approach involving the integration of MAS embedded into microcontrollers to transform an IoT “thing” into a “smart thing.” This proposal was oriented to control lights in an ambient intelligent scenario. Once a smart thing becomes part of the Internet of Smart Things, it can interact seamlessly with other devices within the system, performing tasks to mitigate processing bottlenecks or undesirable delays.

Against this background, Pantoja et al. [16] demonstrated that agents can be embedded either as single entities or as MAS on boards to control specific IoT devices. Selecting one option or another depends on the problem to be solved and the type of IoT device required. However, this research emphasizes the paradigm in which an agent is embedded into a board. In this sense, complementary to the aforementioned proposals, Holgado-Terriza et al. [8] presented an approach for developing IoT devices. The smart agent-based IoT (sabIoT) device was based on Raspberry Pi 4 and the OsBrain platform version 0.6.5, focusing on enhancing the autonomy and proactive interaction of devices connected to an IoT network. In their proposal, the authors highlighted the limitation that Pyro4 does not encrypt the data sent over the network, so they have to work on trusted networks or on properly encrypted/safe communications. This study addresses that limitation because it is an aspect that must be improved to implement the concept of agents of things in real-world contexts where vulnerabilities abound in both agents and entities accessing the Internet.

In the context of software agents for IoT devices, also called agentification over IoT devices [1], the integration of Pyro4 offers significant advantages for implementing efficient communication mechanisms, enabling the simplified management of connections essential for agents operating on different network nodes. This fosters effective collaboration in executing complex tasks. Additionally, Pyro4’s service discovery mechanism facilitates the identification and coordination of agents, enhancing the flexibility and scalability of MASs. Furthermore, its remote object interface simplifies interaction between distributed agents, laying a solid foundation for developing intelligent and adaptive agent systems in distributed environments [8,17]. Thus, Pyro4 emerges as a robust and efficient infrastructure, empowering the development of distributed intelligent agents for advanced scientific and technological applications.

The objective of this investigation is to propose a novel architecture that promotes secure and effective cooperation among autonomous agents operating within IoT systems, applicable in intelligent environments such as Industry 4.0, smart cities, smart homes, and others. The designed mechanisms address the dynamic needs of agents and services while ensuring a secure operational environment against external threats, including identity-based attacks. To achieve this, an architecture has been established to create a network of agents embedded into IoT devices, enabling them to interact and collaborate within complex and dynamic environments more autonomously and smartly, as is proposed by Pico-Valencia et al. [1].

This work is primarily motivated by the fact that, within the agent-based systems context, security remains a critical challenge [6]; however, some studies that apply agents did not pay attention to this issue [10,12,18]. Further efforts are required to develop and introduce mechanisms that allow agents to conduct communication, interaction, and collaboration with trusted entities in a secure and reliable manner. Agents must implement authentication and authorization mechanisms to avoid attacks [9]. In this sense, the proposed framework puts a particular emphasis on describing its key mechanisms to manage secure communications and collaborations in IoT, including the Nameserver, Daemon, Gateway Manager, and Yellow Pages.

The proposed architecture introduces a Nameserver Daemon for secure agent admission and coordination, employing whitelist and blacklist validation, Time-Based One-Time Passwords (TOTP)-based authentication, and cryptographic verification. Unlike existing agent frameworks for IoT that typically assume trusted or closed environments and rely on transport-level security or external infrastructures, LightGuardAgents embeds these security mechanisms directly into the agent lifecycle and registration process. In addition, the architecture combines TOTP-based authentication with a lightweight key distribution mechanism through the Yellow Page, avoiding reliance on heavyweight PKI infrastructures commonly adopted in service-oriented or cloud-centric solutions. Finally, a modular agent lifecycle is defined to support secure deployment and interaction of agents on both general-purpose computers and resource-constrained IoT devices, while maintaining low computational overhead and enabling operation in open and potentially untrusted environments.

These mechanisms ensure data security and effective coordination among IoT devices managed by embedded agents through a multi-level security framework that includes symmetric, asymmetric, and hybrid encryption, as well as TOTP-based authentication. The use of TOTP requires the client and server to maintain clock synchronization within an acceptable tolerance, ensuring that the time-sensitive tokens generated by the client fall within the validation time window on the server [19,20]. Additionally, scalability and adaptability are guaranteed in agent-based IoT ecosystems, enabling the seamless integration of additional agents and dynamic adjustments without the need for extensive reconfigurations. This is particularly important given the highly dynamic nature of IoT implementations, where devices are frequently added or removed throughout the system’s lifecycle.

From an operational and methodological perspective, the architecture is defined under a set of assumptions and constraints inherent to distributed IoT environments. It assumes the availability of basic IP-based connectivity among devices and agents operating in potentially open and untrusted networks. The architecture targets resource-constrained devices while remaining deployable and evaluable on general-purpose computing platforms for architectural validation purposes, where limitations in computational power, memory, and energy consumption must be considered. It is further assumed that participating devices operate within the time tolerance window required to satisfy the TOTP synchronization constraints described previously. From a methodological perspective, this work focuses on architectural design and validation rather than exhaustive performance optimization or large-scale deployment evaluation. These assumptions and constraints define the operational boundaries of the proposed framework and provide context for the experimental validation presented in this study.

This paper is organized as follows. Section 2 describes the research methodology adopted in this study, outlining the design-oriented and experimental approach used to develop and validate the proposed architecture. Section 3 presents the LightGuardAgents architecture in detail, including its main components, security mechanisms, agent lifecycle, and communication processes. In Section 4, a representative case study is introduced to validate the functional behavior, security integration, and feasibility of the proposed architecture in a distributed IoT environment. Section 5 discusses the experimental results, focusing on performance, security mechanisms, scalability, and resilience under dynamic and partial failure conditions. Finally, Section 6 summarizes the main conclusions of this work and outlines potential directions for future research.

2. Methodology

This research follows a design-oriented and experimental methodology, focusing on the proposal, instantiation, and validation of a secure and lightweight multi-agent architecture for Internet of Things (IoT) environments. Rather than adopting a data-driven or model-training approach, the study prioritizes architectural design, system integration, and operational validation. This approach aligns with standard practices in agent-based and distributed systems research, where the primary objective is to demonstrate the feasibility and robustness of novel structural mechanisms.

The methodological process is structured into a sequence of well-defined stages that guide the development and evaluation of the proposed LightGuardAgents architecture. These stages ensure clarity, reproducibility, and alignment with the constraints inherent to resource-constrained IoT environments.

• Stage 1: Design of the IoT Network Environment. The first stage defines the target IoT environment in which the architecture will operate. This includes identifying heterogeneous devices, network connectivity assumptions, and execution platforms ranging from general-purpose computers to embedded systems. The goal of this stage is not performance optimization but to establish a realistic and representative execution context for distributed agents.
• Stage 2: Construction of the Agent Ecosystem. In the second stage, the ecosystem of autonomous agents is designed, including their roles, interaction model, and lifecycle. This stage defines how agents are instantiated, discovered, registered, and coordinated within the system. Emphasis is placed on modularity and decentralization to support scalability and adaptability in dynamic IoT scenarios.
• Stage 3: Integration of Security Mechanisms. The third stage focuses on embedding security mechanisms directly into the agent’s lifecycle. Authentication, access control, and secure communication mechanisms are integrated as native architectural elements rather than external layers. This stage includes the incorporation of TOTP-based authentication, cryptographic key generation, hybrid encryption strategies, and access control through whitelists and blacklists, ensuring secure operation in open and potentially untrusted environments.
• Stage 4: Architectural Instantiation and Operational Flow Definition. Once the architecture and security mechanisms are defined, the system is instantiated through a structured operational workflow. This stage formalizes the sequence of interactions between core components and agents, ensuring that the architecture can be deployed and executed in a reproducible manner across different platforms. The operational behavior is later formalized through high-level pseudocode to enhance clarity and replicability.
• Stage 5: Experimental Validation and Evaluation. The final stage consists of validating the proposed architecture through a representative case study. The evaluation focuses on functional correctness, secure agent interaction, scalability, fault tolerance, and performance under realistic conditions. Rather than relying on statistical learning metrics, the evaluation assesses architectural behavior, operational latency, and the effectiveness of the integrated security mechanisms.

Throughout all stages, the methodology explicitly considers the assumptions and constraints typical of IoT environments, such as limited computational resources, heterogeneous hardware, and basic time synchronization requirements for authentication. These considerations provide a realistic framework for interpreting the experimental results and defining the scope of applicability of the proposed architecture.

3. Architecture for Developing LightGuardAgents

3.1. Overview and Scope

The LightGuardAgents architecture is proposed as a response to the limitations observed in existing embedded agent system architectures for IoT, which predominantly focus on controlling smart environments. These prior works generally assume operation in closed or trusted environments (e.g., [13,15]) and thus offer limited or no explicit treatment of security aspects such as encryption, authentication, or access control. In contrast, LightGuardAgents places security at the core of its design, integrating robust mechanisms including hybrid encryption, TOTP-based authentication, and access control through whitelists and blacklists. These features are embedded throughout the agent interactions and lifecycle, ensuring that the system can operate securely even in open and potentially vulnerable contexts like industry, smart cities, and others.

Beyond security, the architecture is designed for lightweight deployment, enabling its integration into resource-constrained IoT environments without sacrificing functional capacity. It adopts a modular, distributed design that supports scalability across diverse and expanding networks of agents.

3.2. Main Components

The architecture for multi-agent systems in the context of the IoT introduces a robust and scalable infrastructure, built on Python 3.11.3 and Pyro4, which serves as the central pillar supporting the entire proposed architecture. As shown in Figure 1, it enables seamless and secure interactions among the various system components, such as the Yellow Page, which ensures precise service identification by facilitating centralized registration and efficient remote communication between all entities. This component further offers advanced service discovery capabilities, while the Nameserver Daemon enforces rigorous security controls, and the Gateway Manager acts as an interaction channel with external entities that have not yet been verified. This strategically designed synergy fosters dynamic and adaptable collaboration among autonomous agents programmed in Python, establishing a framework in which agents can cooperate and perform reliable tasks.

Within this ecosystem, the Nameserver Daemon plays a crucial role by intercepting all agent registration requests. This process begins with verifying each agent against a blacklist and whitelist, followed by the evaluation of shared keys and the application of rigorous security mechanisms to ensure that only authorized agents can access and participate in the network. Security is a top priority in the proposed architecture and is reinforced through the implementation of symmetric, asymmetric, and hybrid encryption, shared keys, and TOTP authentication. These measures ensure comprehensive protection of communications, creating a resilient operational environment against both external and internal threats, emphasizing the focus on maintaining the integrity, confidentiality, and authenticity of interactions within the system.

The proposed architecture stands out not only for its robust security and adaptability but also for its scalability, enabling the efficient management of an increasing number of agents and services. The advanced functionality of the Yellow Page facilitates resource management and enhances operational efficiency, marking a significant step forward in the field of multi-agent systems for IoT. This proposal offers intelligent and collaborative integration among devices and services, strengthening the way they interact in the complex and dynamic environments of IoT.

A more detailed description of the main components that are part of the proposed architecture is described as follows:

• Nameserver. The Nameserver acts as the core of the multi-agent system architecture for IoT, providing a centralized mechanism for the registration and discovery of services within the network. This component is crucial for maintaining the network space where entities can interact and collaborate. Through its integration with Pyro4, the Nameserver enables agents to locate other services or agents required for the execution of their tasks, optimizing communication and resource distribution in a highly dynamic and distributed environment. This centralization fosters effective communication, efficient real-time request management, and optimized task distribution, ensuring the availability and rapid access to the information needed for interaction among the system’s entities.
• Nameserver Daemon. This is an essential component of the Nameserver, responsible for intercepting all inbound registration and communication requests. By implementing an additional layer of verification and authorization, it ensures that only authenticated and authorized agents and services can operate within the network. This is achieved through rigorous security policies and access control mechanisms, including verifying requests against whitelists and blacklists, TOTP authentication, and the implementation of detailed encryption mechanisms. By validating shared keys and authenticating agents through advanced encryption procedures, Daemon ensures that only verified participants access the network resources. This approach guarantees robust protection against unauthorized access and malicious attacks, maintaining the integrity and confidentiality of communications within the network.
• Gateway Manager. The Gateway Manager focuses on facilitating external communication, acting as an intermediary that connects agents with the Yellow Page during the registration process, without directly exposing the Yellow Page to external agents. Although the Gateway itself does not directly implement security mechanisms, it plays a crucial role by exposing a specific method for agent registration. This method is systematically intercepted by the Nameserver Daemon to perform the necessary security verifications. In this way, the Gateway provides a controlled pathway for communication between agents and the Yellow Page, emphasizing the importance of the Daemon in safeguarding and managing access within the proposed architecture, where security and operational efficiency are paramount.
• Yellow Page (YP). The Yellow Page is responsible for storing and updating information about agents registered in the system. It contains a directory of services where each entry corresponds to an agent and its characteristics, such as name, identifier, services, status (active or inactive), and address. This data enables agents to locate and contact other agents offering the required services. Therefore, the Yellow Page handles agent registration and deregistration requests as well as notifications of changes in status or information. In this way, the Yellow Page serves as a reliable and up-to-date source of information about the agents and services available in the network. It is accessible only through the Gateway Manager, which, with the help of the Nameserver Daemon, filters and controls external communications. Thus, Yellow Page maintains the integrity and privacy of agent data, preventing potential attacks or malicious intrusions. The Yellow Page is a key element in architecture, as it provides an efficient and secure mechanism for agent and service discovery and coordination.
• Agents. Conceptually, in the context of the proposed architecture, an intelligent agent is presented as an autonomous and reactive entity, intrinsically linked to the infrastructure composed of the Nameserver, the Gateway Manager, and the Yellow Page. These agents operate as independent nodes with the ability to carry out specific tasks, interacting securely and effectively within the implemented ecosystem. Upon activation, each agent locates the Nameserver and integrates into the established network space. However, for full participation and effective communication with other agents, they must register through the Gateway Manager, undergoing a meticulously orchestrated security process managed by the Nameserver Daemon.

3.3. Initial Configuration Process

Before an agent begins its registration process within the architecture, it is crucial to properly establish and configure the Nameserver, Gateway Manager, and Yellow Page. This initialization process will lay the foundation for the secure and efficient operation of the entire network. Below is a UML sequence diagram (Figure 2) and the description of the steps involved in this preliminary phase.

The initialization process of the Nameserver establishes the foundation for a secure infrastructure within the device management system. Upon startup, the Nameserver loads the whitelist and blacklist, activates the authentication module, and generates a QR code that enables the administrator to obtain the TOTP code. This mechanism ensures that only authorized devices can join the network, providing a robust and controlled first layer of security.

Before deploying the Yellow Page component, the IP address of the device hosting it must be specified. This step is essential to ensure that the Nameserver and its components can reliably locate the Yellow Page within the network environment, thereby preventing malicious entities from impersonating it. Once operational, the Yellow Page allows the administrator to generate a random key from its main menu, which will be used to establish secure communication with the Nameserver.

With the shared key generated, the Nameserver initiates an active search for the Yellow Page within the network space. Once detected, the administrator is prompted to input the previously generated shared key. This key is verified through the generation of a hash that combines it with the public metadata of the Yellow Page, ensuring authenticity. Upon successful verification, the system grants access to the Nameserver’s options menu, from which the administrator can manage control lists, view active devices, and retrieve the shared key required for registering new agents.

This initial procedure not only ensures a secure and controlled environment for the integration of agents but also establishes a robust and flexible security framework for operating the IoT ecosystem. With the Nameserver, Gateway Manager, and Yellow Page correctly configured and synchronized, the network is prepared to initiate the agent registration and integration process. From this foundation, the agent can begin locating the Nameserver and the network space, marking the starting point of its active participation in the multi-agent system architecture.

3.4. Agent Registration Process

The registration and interaction process of an agent in the proposed architecture is developed through orchestrated steps, ensuring a secure and efficient integration into the network. This process not only facilitates the entry of new agents into the system but also lays the foundation for future communication and collaboration between agents. The following UML sequence diagram of Figure 3 outlines this process step by step.

The agent registration process, as depicted in the sequence diagram, begins with the administrator entering the shared key provided by the Nameserver and the essential data related to the agent, such as its name and capabilities. This information, once entered into the agent, allows it to symmetrically encrypt its communications with the Nameserver, ensuring that the data exchange remains private and secure. Upon initialization, the agent connects to the network space using the IP address of the Nameserver, entering the system as an unregistered entity with no permission to interact with other components.

The agent then generates an asymmetric key pair (public and private keys) to be used for secure message encryption and decryption. This key pair forms part of the data encapsulated within a registration packet, which also includes a TOTP code for temporary verification. The data is encrypted using a hash constructed from the shared key and agent metadata, and the complete packet is then encrypted again using a key known to the Nameserver. Once prepared, the encrypted registration packet is sent to the Gateway Manager using a specific exposed method, where it is intercepted by the Nameserver Daemon.

Upon interception, the Nameserver Daemon verifies whether the agent’s metadata is on the whitelist or blacklist. If the agent is blacklisted, the registration is immediately rejected. If whitelisted, the Daemon proceeds to decrypt the packet. Successful decryption leads to TOTP code validation. If valid, the Daemon creates a new packet incorporating the original information, encrypts it with a shared key and metadata unique to the Yellow Page, and forwards it. The Yellow Page then decrypts this packet using its own metadata and the shared key, extracts the agent’s public key, and generates a new asymmetric key pair specifically to communicate securely with the agent. This new key pair is associated with the agent’s original key and ensures encrypted, authenticated communication.

Following successful validation, the Yellow Page informs the Nameserver Daemon, which passes the response to the Gateway Manager, returning the Yellow Page’s public key to the agent through a hybrid encryption method. The public key is encrypted using a randomly generated symmetric key, which in turn is encrypted with the agent’s public key. Only the agent can decrypt the message using its private key, ensuring confidentiality and integrity. With this, the registration process concludes, and the agent establishes a direct, secure communication channel with the Yellow Page. The agent is now able to interact with other agents securely, leveraging the directory maintained by the Yellow Page and contributing to a resilient, secure multi-agent IoT ecosystem.

A detailed pseudocode describing the agent registration process is provided in Appendix A.1. The pseudocode also illustrates the key generation procedure and explains how an agent is registered within the platform through the Gateway Manager, enabling it to establish secure communication with other agents already registered in the system.

3.5. Process of Delivering the Agent’s Public Key to the Yellow Page

To carry out the process of Delivering the Agent’s Public Key to the Yellow Page, ordered steps must be followed. These steps are illustrated in Figure 4.

The process of delivering the agent’s public key to the Yellow Page begins with the user entering the TOTP code, which is obtained by scanning a QR code previously generated by the Nameserver through applications such as Google or Microsoft Authenticator (5.0). Immediately afterward, the user inputs the shared key provided by the Nameserver, which will be used to encrypt all data transmitted during the registration process. With these elements, the agent proceeds to automatically generate an asymmetric key pair—consisting of a public key and a private key—which will serve as the basis for secure communication within the system.

Once the asymmetric key pair is generated, the agent encrypts the registration information intended for the Yellow Page. This includes its metadata and the public key, all protected using the shared key to ensure confidentiality. The resulting encrypted packet is then sent via the Gateway Manager and intercepted by the Nameserver Daemon. Upon interception, the daemon verifies the metadata associated with the agent and evaluates whether its IP address is included on the blacklist. If so, the request is immediately rejected. Otherwise, the system checks if the IP address is included in the whitelist. If the agent is approved, the daemon proceeds to decrypt the packet.

In cases where the packet is successfully decrypted, the daemon validates the TOTP code to confirm the authenticity of the request. If the validation is successful, the daemon creates a new encrypted packet, incorporating the original agent data along with internal private information. This newly formed packet is encrypted using a unique hash generated from the shared key between the Nameserver and the Yellow Page, combined with public metadata of the Yellow Page. Once complete, the encrypted packet is forwarded to the Yellow Page, which proceeds to decrypt it, extract the agent’s public key, and generate a new asymmetric key pair to be associated with the agent. The Yellow Page then notifies the Nameserver Daemon that the key generation process has concluded successfully.

In the final stage, the Nameserver Daemon—unable to communicate directly with the agent—uses the Gateway Manager to forward the Yellow Page’s response. The Yellow Page receives the request to deliver the public key and searches for the appropriate public key associated with the agent’s original request. Using hybrid encryption, the Yellow Page encrypts the newly generated public key with a randomly generated symmetric key and then encrypts that symmetric key with the agent’s public key. The agent then decrypts the symmetric key with its private key and uses it to decrypt the public key. This establishes a secure and authenticated channel between the agent and the Yellow Page. From this point onward, communication can occur directly between them without the need for intermediaries, completing the secure integration of the agent into the system.

3.6. Process of Updating Yellow Page Directory

Figure 5 illustrates the elements involved in the Procedure for Delivering the Agent’s Public Key to the Yellow Page. The diagram also outlines the step-by-step process followed during this procedure. Additionally, it displays the methods published by each agent and the metadata made available in the Yellow Pages. These methods are refreshed once agents receive the updated directory.

The Yellow Page is responsible for maintaining an up-to-date directory of all registered agents within the system. This directory includes essential information such as each agent’s name, description, skills, and public key. Whenever a new agent is registered, or the data of an existing agent is modified, the Yellow Page initiates an update process. As part of this process, the updated directory is distributed to all registered agents, allowing them to communicate directly with one another without needing to rely on the Yellow Page for each interaction.

To ensure the confidentiality of this shared information, the Yellow Page encrypts the directory individually for each agent using their respective public keys. This means the system iterates through every active agent and generates a uniquely encrypted version of the directory for each one, safeguarding the information from unauthorized access during transmission.

Once the encryption process is complete, the Yellow Page transmits the respective encrypted versions of the directory to each agent. Upon receiving the directory, each agent uses its private key to decrypt the randomly generated symmetric key that accompanied the transmission. This symmetric key is then used to decrypt the directory itself, granting the agent access to the most recent information about its peers and enabling secure, direct communication within the network.

3.7. Multi-Agent Communication Process

To ensure the effectiveness of the communication process in a multi-agent environment, it is essential that all agents are previously authenticated and validated by the Nameserver Daemon and registered on the Yellow Page. Once these prerequisites are met, the Yellow Page provides each agent with an updated directory of agents (Figure 6), enabling them to establish secure and collaborative communications.

This process is based on a hybrid encryption strategy, where the sender agent selects the recipient agent’s public key from the directory to encrypt a randomly generated symmetric key. This symmetric key is then used to encrypt the request data, which is sent to the recipient along with the symmetric key encrypted using the recipient’s public key.

Upon receiving the request, the recipient agent uses its private key to decrypt the symmetric key and then uses the symmetric key to decrypt the request data. After processing the received information, the recipient responds to the sender agent using the same encryption mechanism, thereby ensuring a secure and efficient exchange of information.

This method not only protects the integrity and confidentiality of the exchanged data but also facilitates effective and secure collaboration among agents within the system.

To illustrate the methods that enable agent-to-agent communication using the security mechanisms embedded in both the agents and the components of the proposed architecture, Appendix A.2 presents a pseudocode describing the actions implemented to achieve secure communication through agents that incorporate the security features of LightGuardAgents.

3.8. Operational Workflow

In this work, the methodological workflow does not follow a data-driven or model-training pipeline. Instead, it is defined by an architectural and operational flow that describes the lifecycle of embedded agents within the proposed system. This workflow links system initialization, secure agent registration, service discovery, agent interaction, and architectural evaluation, providing a clear view of how the proposed architecture is instantiated, executed, and assessed.

Although the proposed system is not defined through a traditional algorithmic model, its behavior can be described through a structured operational procedure. Therefore, a high-level pseudocode is provided to formalize the sequence of interactions required to instantiate and execute the proposed architecture in a reproducible manner. This pseudocode abstracts implementation-specific details and focuses on architectural interactions rather than concrete programming constructs.

Based on the pseudocode presented in Algorithm 1, the operational flow of the system describes in a structured manner how the proposed architecture is instantiated and executed. The process begins with the initialization of the core infrastructure components, namely the Nameserver, the Gateway Manager, and the Yellow Page, which together establish the network space where agent interactions take place. In parallel, access control policies are loaded, and authentication and encryption mechanisms are activated, ensuring that the architecture operates within a secure environment from its earliest stages. At this point, the system verifies the existence of a secure association between the Nameserver and the Yellow Page; if such an association is not already established, a secure communication channel is created to enable trustworthy registration management and service publication.

Algorithm 1. Macro-operational orchestration of LightGuardAgents

Input: System configuration; provisioned secrets (K_A↔NS, K_NS↔YP); network connectivity.

Output: Running architecture with registered agents, updated directory, and secure A↔A channels.

1:    INITIALIZE Nameserver; INITIALIZE GatewayManager; INITIALIZE YellowPage

2:    LOAD AccessControlPolicies; ACTIVATE AuthenticationMechanisms; ACTIVATE EncryptionMechanisms

3:    if SecureAssociation(Nameserver, YellowPage) == NOT_ESTABLISHED then

4:              ESTABLISH SecureChannel(Nameserver, YellowPage)

5:    end if

6:    for each Agent in System do

7:              ACTIVATE Agent; CONNECT Agent to NetworkSpace; SET Agent.Status ← UNREGISTERED

8:              Agent.GENERATE_Credentials()

9:              SEND RegistrationRequest to Nameserver via GatewayManager

10:             if Nameserver.VALIDATE(RegistrationRequest) == ACCEPTED then

11:                      REGISTER Agent in YellowPage

12:                      ESTABLISH SecureChannel(Agent, YellowPage)

13:             else

14:                      REJECT RegistrationRequest

15:             end if

16: end for

17: YellowPage.UPDATE_ServiceDirectory(); DISTRIBUTE ServiceDirectory to RegisteredAgents

18: for each Agent in RegisteredAgents do

19:             Agent.DISCOVER_Services(LocalDirectory)

20:             if ServiceRequest EXISTS then

21:                      ESTABLISH SecureAgentToAgentChannel()

22:                      EXECUTE RequestedService; EXCHANGE ResultsSecurely

23:             end if

24: end for

25: MONITOR AgentInteractions; MAINTAIN DirectoryConsistency

Once the environment is prepared, agents are activated and connected to the network space in an unregistered state. Each agent generates its security credentials and submits a registration request to the Nameserver, which is validated before allowing the agent to join the system. Accepted agents are securely registered in the Yellow Page and establish protected communication channels with this component. Subsequently, the Yellow Page updates and distributes the service directory to all registered agents, enabling decentralized service discovery. Based on this locally stored information, agents can initiate peer-to-peer interactions through encrypted channels, execute the requested services, and exchange results securely. Finally, the system continuously monitors agent interactions and maintains directory consistency, ensuring reliable and coherent operation of the architecture throughout its lifecycle.

3.9. Additional Key Considerations

The proposed architecture incorporates lightweight key management mechanisms suitable for resource-constrained IoT devices. During agent registration, each agent locally generates its own asymmetric key pair, avoiding centralized key generation and the use of certificate authorities.

On the other hand, shared secrets required for initial authentication are provisioned during system initialization and enforced by the Nameserver Daemon. Finally, private keys are stored locally on each device and are never transmitted over the network. Key renewal is handled in an event-driven manner, typically triggered by agent re-registration or security policy enforcement, rather than periodic rotation, in order to reduce computational overhead. Key revocation is enforced through whitelist and blacklist mechanisms managed by the Nameserver Daemon and reflected in the Yellow Page directory. Agents whose credentials are revoked are prevented from further interaction and must re-register to regain access, generating new cryptographic material. These mechanisms provide practical and scalable key management aligned with the lightweight nature of the proposed architecture.

It is worth emphasizing that, although the proposed architecture is illustrated in the context of IoT environments, its design is not inherently restricted to this domain. The core architectural components, including the embedded agent lifecycle, secure communication mechanisms, and authentication strategies, are defined in a modular and implementation-independent manner. As a result, the proposed approach can be extended to other distributed and resource-constrained environments, such as cyber-physical systems, edge computing infrastructures, or distributed embedded systems, provided that suitable communication interfaces and execution platforms are available. Domain-specific adaptations are mainly related to the integration of external services or system interfaces, while the security and coordination mechanisms remain reusable across different application contexts.

4. Case Study

4.1. Scenario

To demonstrate the feasibility of the proposed architecture, a use case involving the deployment of mathematical agents specialized in basic operations—sum, subtraction, and multiplication—has been implemented. The primary objective of this case study is to validate the functional behavior of the proposed agent-based system under real conditions where an agent called the consumer agent coordinates mathematical agents to use their services. In particular, the case study focuses on validating the architectural components and the integrated security mechanisms of the proposed system, rather than optimizing performance for a specific hardware configuration.

Beyond functional verification, the central focus lies in evaluating the architectural components and the integrated security mechanisms that enable the development of lightweight and secure agents suitable for both general-purpose computers and resource-constrained microcontrollers commonly found in IoT environments. This case study examines how the architecture supports secure communication, authentication, data encryption, and agent coordination within a distributed system while maintaining low computational overhead.

Emphasis is placed on the ability of the platform to operate efficiently across heterogeneous hardware, ensuring adaptability and scalability. The selected hardware components serve as an execution environment to demonstrate feasibility and interoperability; therefore, variations in hardware resources may influence absolute performance values without affecting the validity of the proposed architectural design. The hardware components utilized for deploying the distributed agent system, including the computers and embedded devices used in the experiment, are shown in Figure 7, which illustrates the experimental case study scenario implemented using LightGuardAgents.

The case study was conducted under controlled conditions representative of a small-scale IoT deployment. The experimental setup consists of heterogeneous end nodes executing embedded agents, interconnected through a local IP-based network. End nodes include general-purpose computers and resource-constrained embedded devices hosting autonomous agents, while a gateway device acts as the access point for agent registration and external interactions. Core architectural components—such as the Nameserver, Gateway Manager, and Yellow Page—are deployed as dedicated services within the network to coordinate agent discovery, authentication, and secure communication. This configuration enables the evaluation of agent interactions, security mechanisms, and coordination processes across multiple nodes, reflecting realistic IoT network conditions without requiring large-scale infrastructure.

The experimental setup of this study does not rely on datasets, data preprocessing, or train–test splitting procedures typically associated with data-driven or machine learning approaches. Instead, validation is conducted through a case study that instantiates the proposed architecture and evaluates agent interactions under predefined operational scenarios. The experimental evaluation focuses on architectural behavior, secure communication mechanisms, and functional execution of agent services, rather than on statistical learning or data-based performance assessment.

4.2. Physical Network of Devices

The main objective is to verify the functionality and security of the proposed architecture, as well as the interaction between the various entities involved within a distributed environment.

Table 1. Equipment and entities implemented in the use case.

Hardware	Software	IP	Entity
Desktop PC AMD Ryzen 7 5800X 8-Core Processor Frequency 3.8 GHz 16 GB memory RAM	Windows 11 Pro Python 3.11.3	192.168.1.16	Nameserver
Laptop Asus Intel Core i5-10300H Frequency 2.5 GHz	Windows 11 Home Single Language Python 3.11.3	192.168.1.12	Yellow Page
Laptop Asus Intel Core i5-7200U CPU Frequency 2.5 GHz 12 GB memory RAM	Windows 11 Pro Python 3.11.4	192.168.1.18	Agent Subtraction
Laptop Dell Intel Core i5-4200U Frequency 1.6 GHz 8 GB memory RAM	Windows 11 Pro Python 3.12	192.168.1.17	Agent Consumer
Laptop HP AMD Ryzen 7 5800H 8-with Radeon Graphics Frequency 3.2 GHz 32 GB memory RAM	Windows 11 Pro Python 3.11.7	192.168.1.10	Agent Multiplication
Raspberry Pi 4 Model B Rev 1.2 CPU 4x ARM Cortex-A72 r0p3 (AArch64) Frequency 4 GB memory RAM	Debian GNU/Linux 12 (bookworm) Python 3.11.2	192.168.1.19	Agent Sum

details the hardware used for the deployment of the architecture, specifying also the software characteristics, IP addresses, and the entity responsible for their execution. All equipment was sourced from local suppliers in Barranquilla, Colombia.

4.3. Multi-Agent System

4.3.1. Configuring Proposed Architecture’s Own Elements

Initially, the Nameserver and the Yellow Page are running on separate machines. Therefore, when the deployment is carried out for the first time, the Nameserver must be provided with the IP address of the machine where the Yellow Page is located. Similarly, the Yellow Page must be provided with the IP address of the machine running the Nameserver, allowing both machines to establish communication. Once the Nameserver indicates that it has found the Yellow Page, it requests the shared random key generated by the Yellow Page (in this case, LQb5Ia), which can be viewed through the Yellow Page’s menu. If everything is correct, the architecture is ready to receive registration requests from agents, as shown in Figure 8. If the architecture has already been deployed on the same machines with the same IP addresses, it will no longer be necessary to input the IP addresses during initial execution, as this information will be stored in an encrypted file to facilitate and speed up the deployment. Additionally, if both entities are running on the same machine, entering the IP addresses is not required.

The system also facilitates the visualization of logs corresponding to the executions performed by each entity. Figure 9 shows a fragment of the Yellow Page logs. These logs highlight various processes, such as the generation of the shared key, agent registration, encryption, and decryption of information. Additionally, if there are agents registered in previous sessions, the system will attempt to automatically reload the list of these agents.

After starting the Nameserver and the Yellow Page, the agents are deployed on different devices within the same network. The entities deployed were: agent sum, agent subtraction, multiplication, and agent consumer, which will act as the consumer agent for the services offered by the other agents.

For the case study, the sum agent was deployed on a Raspberry Pi 4. It can be observed that when attempting to start the agent, a shared key is required. This key is randomly provided by the Yellow Page. For practical purposes in this use case, the shared key was set by default to abcd123. After this, it is necessary to input a description and the agent’s capability, as well as the IP address of the Nameserver. If the agent is being executed on the same machine as the Nameserver, this field can be left blank by simply pressing enter, as it will automatically default to the machine’s IP address.

Following this step, the TOTP code generated by the Nameserver must be entered to complete the registration. If an incorrect code is entered, the system will notify the user and prompt for the correct code to successfully register the agent. If the TOTP code entry fails five times, the registration attempts will be interpreted as malicious. Consequently, the agent’s IP address will be added to the blacklist, blocking any further registration attempts from that address. Only the system administrator can modify the blacklist or whitelist to add or remove IP addresses.

After the agent registration is complete, a menu is displayed that allows users to: obtain information about the agent, view the agent’s logs, and review the requests and responses executed by the agent. The menu also includes an option to terminate the agent’s execution. It is important to note that this process applies to any agent deployed within the architecture unless the agent has been registered by the network administrator by adding its IP address to the Nameserver’s whitelist. This bypasses the requirement for the agent to enter the TOTP code. For the purposes of this use case, the IP address of the multiplication agent was added to the whitelist.

The registration of the multiplication agent’s IP address (192.168.1.10) was directly realized into the whitelist. Additionally, it is possible to view the list of IPs registered in the whitelist, corresponding to agents that have been successfully registered: sum agent (192.168.1.19), subtraction agent (192.168.1.18), and multiplication agent. It is emphasized that the multiplication agent can also be registered without the need to enter the TOTP code. This is possible because the IP address of the machine running this agent was previously added to the whitelist.

Finally, the consumer agent is created and registered. This agent will be responsible for making requests to the agents registered in the Yellow Page (see Figure 10).

Thus, once the agents are registered, it is possible to view all registered agents through the Yellow Page, including their IDs, names, descriptions, skills, and IP addresses. This list is shared by the Yellow Page with every agent in the network and is constantly updated, allowing agents to establish connections with newly added agents:

• ID: 7e51b1df-6217-4c11-82a1-6b5de716cc2e, Name: Multiplication, IP: 192.168.1.10, Description: multiplication, Skills: [‘multiply’]
• ID: 8363b1e6-093c-4880-a550-9e60ff274bc4, Name: Sum, IP: 192.168.1.19, Description: sum, Skills: [‘add’]
• ID: f58cf5b6-b0ad-447f-bd6a-0f78db97eda4, Name: Subtraction, IP: 192.168.1.18, Description: subtraction, Skills: [‘subtract’]
• ID: aa542417-6cbf-4a19-8606-dc90dbd765d, Name: AgentConsumer1, IP: 192.168.1.17, Description: consumer, Skills: [‘consume’]

4.3.2. Process for Invoking Service’s Agents

When the consumer agent needs the service of other agents, it is possible to view the list of available agents on the network and also choose which agent to connect with in order to make a service request, considering the skills offered by the agents performing actions.

Then, the subtraction agent is chosen to perform operations. At this point, communication is established directly between the consumer agent and the subtraction agent, without the need for intervention from the Yellow Page. The subtraction agent indicates the necessary parameters that the consumer agent must provide in order to execute the operation. Once the consumer agent supplies the data, the subtraction agent performs the operation and returns the result. It is important to highlight that these communications between agents are entirely encrypted. The subtraction agent keeps a traceability of the requests it has received and the responses it has provided as follows: Request ID: 941463b6-ab36-448d-a2d4-310e8497baa8 | Data: num1: 50.0, num2: 15.0 | Result: 35.0.

It is important to highlight that once the registered agents receive the agent directory from the Yellow Page, the agents are capable of establishing communication with other agents and performing activities. Even if the Yellow Page stops operating for any reason, it would not affect the execution of activities between registered agents. The only ones that would be affected are the new agents attempting to register. When the Yellow Page resumes operations, it will automatically update the list of registered agents since it has an encrypted backup of this information. Once the execution begins and the agent directory is updated, it will be ready to receive new registration requests.

This use case has successfully demonstrated the functionality and security of the proposed architecture by running mathematical agents in a distributed environment. The ability to deploy agents on independent devices and manage secure communications through shared keys and TOTP codes highlights the system’s robustness in terms of operational and security needs. A detailed tutorial of the execution of the case study can be accessed in the following repository: https://github.com/Sistemas-Concurrentes/LightGuardAgents (accessed on 13 January 2026).

The correct implementation of the Nameserver and Yellow Page not only facilitated communication between agents but also contributed to the efficient recovery and management of sensitive data registered in previous Yellow Page executions, strengthening the system’s resilience against disruptions caused by this entity. Furthermore, the agents’ ability to register, update the agent directory, and communicate securely using encrypted information presents a promising outlook for the development of more complex, efficient, and secure systems. This use case validates the proposed architecture in practical terms.

4.4. Evaluation of Performance of Agents

The performance evaluation focuses on execution time, operation latency, event frequency, and system responsiveness, as these metrics directly reflect the computational overhead introduced by the proposed architecture. In resource-constrained IoT environments, factors such as memory usage, CPU availability, and energy consumption are strongly correlated with the duration and frequency of cryptographic operations, agent registration, and inter-agent communication. Therefore, measuring execution times of core processes—such as registration, authentication, service discovery, and secure communication—provides a practical and representative assessment of whether the architecture can operate efficiently on devices with limited resources. Rather than emphasizing throughput or large-scale stress testing, which is beyond the scope of this work, the selected metrics validate that the integrated security mechanisms do not impose prohibitive delays or operational bottlenecks, supporting the suitability of the proposed architecture for lightweight IoT deployments.

From an experimental perspective, the performance evaluation of the proposed architecture was conducted through a session lasting approximately 18.9 min (1134.47 s), during which the system remained active and operational. This time window, between 14:05:02 and 14:23:56, allowed agents and clients (consumer agents) to register and interact with the Yellow Page component, performing service queries and communication tasks.

To assess the system’s efficiency and responsiveness, operational time metrics were analyzed for two groups: embedded agents and consumer clients. A total of 1084 agent operations and 92 client operations were recorded with execution times greater than zero. Descriptive statistics show that the median execution time was ≤0.001 s for both groups and that 75% of the operations were completed in less than 0.002 s for agents and less than 0.11 s for clients. These results, described in more detail in

Table 2. Operating Time Statistics for Agents and Clients.

Statistics	Mathematical Agents	Consumer Agents
Count	1084	92
Mean	0.104664	0.083583
Std	0.350769	0.187542
Min	0.000009	0.000009
25%	0.000029	0.000087
50%	0.000835	0.001627
75%	0.00208	0.11012
Max	2.280475	0.818837

, confirm that most operations occur with very low latency, demonstrating the lightweight nature of the architecture.

However, a small number of outliers were identified, with maximum execution times reaching 2.28 s for agents and 0.82 s for clients. These values correspond to batch agent creation events, which involve additional operations such as encryption, key validation, and TOTP verification. These more complex tasks increase processing time during specific phases such as END_REGISTRATION and END_TIME_TOTAL_REGISTRATION, as illustrated in Figure 11. Despite these peaks, the system sustained efficient operation with no signs of systemic bottlenecks.

Further validation of the architecture’s lightweight performance was obtained by analyzing the duration and frequency of agent operations. Throughout the 18.9 min session, a total of 1974 events were recorded in the Yellow Page, and over 1000 agent operations were tracked. More than 75% of agent activities were completed in under 0.002 s, while client operations maintained a similarly high success rate above 99%. Registration and authentication processes, including REGISTRATION, PREREGISTRATION, and related events, are consistently completed in under one second, indicating minimal overhead from the security mechanisms.

To reinforce the evaluation, a dynamic performance scenario was simulated by introducing new agents into an active system. These agents successfully integrated into the ecosystem without requiring the restart of central services. The Nameserver and Gateway Manager components updated their internal directories immediately, and the communication latency between existing and new agents remained stable. This confirms that the architecture supports dynamic scaling and self-adaptation without service interruption.

A resilience test was also performed by intentionally disabling the Yellow Page component to observe system behavior under partial failure. Agents previously registered and holding encrypted directory data continued to operate and communicate with each other, validating the system’s support for decentralized communication. While the registration of new agents was temporarily affected, once the Yellow Page was restored, it resumed its functions using encrypted backups and reestablished secure synchronization among agents. This behavior confirms the architecture’s fault-tolerant design and its applicability to real-world distributed IoT environments.

To complement the performance metrics, the traceability of system activity was analyzed using logs collected from agents, clients, and the Yellow Page component. As shown in Figure 12, agents—particularly the SECURITY_MANAGEMENT and BASE_AGENT components—were the most active, reflecting their central role in security enforcement and request handling.

The AGENT_CONNECTION_HANDLER also exhibited high activity due to frequent inter-agent communication. On the client side, the REQUEST_MANAGER generated moderate but steady traffic, mostly consisting of service queries. Meanwhile, components of the Yellow Page such as YELLOW_PAGE_INTEGRATION, SECURITY_VALIDATOR, and SYMMETRIC_CRYPTOGRAPHY played a critical but lower-volume role, focused on secure registration, cryptographic operations, and key management.

This component-wise activity breakdown demonstrates that all architectural elements are actively involved in the system’s operation, and that even the most security-intensive modules impose only minimal overhead. Overall, the evaluation confirms that LightGuardAgents operates as a lightweight, scalable, and secure multi-agent system suitable for distributed IoT environments.

4.5. Evaluation of Agent’s Security Mechanisms

This study proposes an architecture designed to support the development of lightweight and secure agent-based systems. To assess its effectiveness, a qualitative evaluation was conducted focusing on three key aspects: the agent registration process, inter-agent communication, and the security mechanisms implemented to ensure reliable interactions.

In the context of multi-agent systems, a wide range of security mechanisms can be applied. The most relevant are outlined below. Some of them have been described in the review carried out by Jung et al. [6]:

• SM1-Agent Authentication. Verification of an agent’s identity before allowing access or interaction.
• SM2—Role-Based Access Control (RBAC). Access control based on the role of the agent or user.
• SM3—Communication Encryption. Encryption of messages between agents to prevent interception.
• SM4—Digital Signature. Ensures the integrity and authenticity of messages sent by agents.
• SM5—Intrusion Detection System (IDS). Monitoring agent behavior to identify malicious activity.
• SM6—Policy-Based Access Control. Allows or denies actions according to predefined security policies.
• SM7—Malicious Agent Isolation. Ability of the system to disconnect or block suspicious agents.
• SM8—Traceability and Audit Logging. Logging actions and events for later forensic analysis.
• SM9—Fault Resilience. Ability of the system to recover or continue operating after attacks or errors.
• SM10—Agent Reputation. Evaluation and management of agents’ behavior history;
• SM11—Agent Sandboxing. Running agents in controlled environments to limit potential damage.
• SM12—Agent Code Verification. Inspection of the agent’s code before it is executed on the platform.
• SM13—Homomorphic Encryption. Enables processing of encrypted data without needing decryption.
• SM14—Secure Consensus Protocols. Ensures collaborative decisions without manipulation in multi-agent environments.
• SM15—Anti-Spoofing Mechanisms. Prevent impersonation between agents.
• SM16—Byzantine Fault Tolerance (BFT). Mechanisms to tolerate malicious agents in distributed environments.
• SM17—Continuous Security Monitoring. Ongoing surveillance of the system’s runtime environment.
• SM18—Self-Assessment and Policy Adaptation. System’s ability to dynamically modify its security rules.
• SM19—Behavior-Based Security. Identification of deviations from an agent’s normal behavior.
• SM20—Multi-Factor Authentication (MFA). Identity verification using multiple factors (password, biometrics).

To conduct the evaluation, a star-based rating system was applied, which allows for the assessment of each implemented mechanism on a scale from 0 to 5, with the following interpretation proposed in [21] for evaluation security mechanisms in cybersecurity:

• ★★★★★ no implemented.
• ★★★★★ implemented with serious limitations.
• ★★★★★ implemented with minor unknown limitations.
• ★★★★★ implemented with known limitations.
• ★★★★★ implemented well, not tested in a real environment.
• ★★★★★ implemented well, tested and verified in a real environment.

The evaluation was carried out on the infrastructure designed for the case study, which included the Nameserver, Daemon, Gateway Manager, and Yellow Pages components. A series of controlled tests were applied to assess nine key mechanisms related to security and reliability, all aligned with the SM1–SM20 taxonomy.

The star-based ratings reported in

Table 3. Evaluation of the security mechanisms implemented by the proposed architecture agent. 0 stars: Not implemented; 1 star: Critical limitations; 2 stars: Minor unidentified limitations; 3 stars: Known limitations; 4 stars: Fully implemented (simulation only); 5 stars: Fully implemented and field-verified.

Tested Mechanism	Category	Scope of Security Mechanism	Scope of the Applied Test	Obtained Results of the Applied Test	Evaluation
Component authentication	SM1	Secure system startup prevents vulnerabilities arising during the agent system’s boot process	Verify that the Nameserver does not start unless the Yellow Page is authenticated and active	Secure initialization is blocked in case of IP errors or inactive services	★★★★★
Unique Key Generation	SM1, SM3	Communication limited exclusively to authorized Nameserver and Yellow Page components	Validate that the shared key generated by the Yellow Page is unique and non-reusable	Systematic rejection of invalid keys; dynamic key generation confirmed	★★★★★
TOTP Authentication + Encryption	SM1, SM3, SM20, SM8	Agent validation is enforced through multi-level security mechanisms based on valid authentication	Create agents using incorrect shared keys and TOTP codes	Strong protection against attacks; the Daemon rejects requests from agents with invalid shared keys and TOTP codes	★★★★
Two-Factor Authentication (2FA)	SM6, SM20	Validation of the two-factor authentication mechanism for agents, which reinforces security and the protection of transmitted data	Use a valid shared key and an incorrect TOTP code to register an agent	Invalid TOTP prevents registration; detailed logging of the entire process	★★★★★
Credential Validation (2FA)	SM1, SM20, SM8	Registration of agents with reliable operational attributes in the Yellow Page	Create agents using correct shared key and TOTP code	Flow successfully validated; agents are listed in the Yellow Page	★★★★★
Communication Integrity	SM3, SM8	Direct data exchange between trusted agents in a multi-agent system	Establish communication between agents while the Yellow Page is active	Effective and logged direct communication	★★★★
Resilience to Service Outages	SM9	Dependency of communications on the Yellow Page service	Verify communication between agents with the Yellow Page inactive	Communication persists; Yellow Page restores state after restart	★★★★
Scalability and Bulk Authentication	SM1, SM6, SM8	Creation of multiple trusted agent instances and validation of their communication and functionality	Create agents in batches and validate interaction among them	Smooth registration and operation of 31 distributed agents	★★★★★
Cryptography and Key Derivation (PBKDF2)	SM1, SM3	Assignment of unique keys for each system agent, ensuring that only trusted agents can decrypt the data transmitted over the network	Ensure each agent has a unique key encrypted with a salt	Robust encryption using SHA512 and random salt per agent	★★★★★
Critical Dependency on the Nameserver	SM9, SM17	System operability level in the event of Nameserver failure	Evaluate system functionality after shutting down the Nameserver	Total inoperability; highlights the need for redundancy	★★★

were assigned manually based on expert judgment, following direct observation of system behavior during the experimental execution. The evaluation was performed by two experts in concurrent systems, who analyzed the extent to which each mechanism was implemented, its operational limitations, and its verification under the tested scenarios, according to the criteria defined in [20]. No automatic scoring or tool-based classification was used in this process.

The mechanisms that received a five-star rating (★★★★★) correspond to critical security features that were implemented with a high degree of robustness, traceability, and effectiveness and were validated under controlled adversarial conditions. For instance, agent authentication (SM1), credential validation using multi-factor authentication (SM20), and secure key derivation with encryption (SM3) were evaluated by intentionally submitting invalid credentials, incorrect TOTP codes, and malformed registration requests. These adversarial attempts were consistently rejected, while exhaustive logging was preserved for both successful and failed authentication events. Additionally, the system demonstrated scalability and reliability through bulk agent creation and concurrent registration attempts, validating policy enforcement (SM6) and audit logging mechanisms (SM8) under elevated operational load.

Mechanisms rated with four stars (★★★★) were well implemented but exhibited potential limitations when exposed to partial adversarial or fault scenarios. Secure inter-agent communication (SM3) was tested under conditions where dependent services, such as the Yellow Page, experienced temporary unavailability, revealing possible bottlenecks during extended downtime. Similarly, TOTP validation was stress-tested using repeated incorrect codes and delayed responses, demonstrating strong resistance to unauthorized access, although additional adversarial countermeasures such as progressive lockouts or automatic isolation of suspicious agents (SM7) could further strengthen defense. Fault resilience (SM9) was evaluated by deliberately disabling selected components, showing partial recovery capabilities but also highlighting a strong dependency on the Nameserver.

The only mechanism receiving a three-star rating (★★★) was related to the architecture’s dependency on the Nameserver, which was explicitly evaluated through an adversarial availability test. When the Nameserver was intentionally taken offline, the system became inoperative, revealing a structural vulnerability and the absence of redundancy mechanisms. The lack of Byzantine Fault Tolerance (SM16), secure consensus protocols (SM14), or continuous security monitoring (SM17) limits the system’s ability to withstand coordinated failures or adversarial disruptions. This result clearly identifies a critical limitation that must be addressed for deployment in real-world distributed environments.

Although a significant subset of the security taxonomy has been covered (SM1, SM3, SM6, SM8, SM9, and SM20), several mechanisms remain unimplemented and represent opportunities for future development. Features such as agent code verification (SM12), digital signatures for message integrity (SM4), and behavior-based intrusion detection mechanisms (SM5) could further strengthen the system under adversarial conditions. Likewise, incorporating agent reputation management (SM10), policy self-adaptation (SM18), and behavior-based security (SM19) would improve resilience against coordinated or persistent attacks. Finally, and no less importantly, the adoption of more efficient and standardized M2M communication technologies—such as Google Remote Procedure Call (gRPC) [21]—is identified as a relevant future direction to enhance interoperability and performance while preserving the security principles validated in this work.

4.6. Evaluation of Multi-Agent’s Scalability

During the initial system evaluation phase, tests were conducted with agents that are part of the ecosystem from the moment of deployment. These tests enabled verification of the stability, synchronization, and efficiency of core processes such as registration, discovery, and inter-agent communication. The results showed that agents successfully registered with the Nameserver through the Daemon and Gateway Manager mechanisms. Likewise, queries and responses via the Yellow Pages directory were resolved with minimal latency and no interference between concurrently operating agents. This behavior validated that, under baseline conditions, the LightGuardAgents architecture operates in a lightweight, efficient, and stable manner, preserving the integrity of the multi-agent ecosystem without introducing network bottlenecks or overloading management modules.

To assess the architecture’s performance under dynamic scenarios, simulations were carried out involving the sequential incorporation of new agents into a system already in operation. These tests confirmed that newly introduced nodes were able to integrate into the ecosystem without requiring a restart of central components and that the Nameserver and Gateway Manager updated their internal records immediately. The average communication latency between new and existing agents remained within the operational range observed during the initial conditions, demonstrating the system’s scalability, adaptability, and robustness in the face of dynamic growth. Additionally, no interference or blocking was detected in the directory services, and coordination between newly added and active agents was established without the need for manual reconfiguration.

The system was also evaluated under conditions simulating partial service disruption by intentionally deactivating the Yellow Pages component. As documented in the architectural specification, agents that had previously registered and received the encrypted directory were able to continue operating and exchanging messages with one another. This confirmed that the architecture supports decentralized communication among agents once the initialization phase is completed. Only the registration of new agents was temporarily impacted. Upon reactivation, the Yellow Pages restored its state automatically from encrypted backups and resumed normal operations, including directory synchronization across agents. This behavior highlights the system’s tolerance to partial failures and reinforces its robustness in real-world distributed environments.

Tests confirm that the proposed architecture is not only functionally sound in distributed IoT environments but also capable of adapting to dynamic changes and partial system failures. LightGuardAgents proves to be a scalable, resilient, and secure solution, fulfilling the requirements of operational continuity, ecosystem integrity, and adaptability in embedded multi-agent systems.

5. Discussion

The architecture proposed in this study for the development of multi-agent systems within the IoT represents a significant advancement in addressing the challenges inherent in distributed systems, such as data security and efficient coordination between autonomous devices—an aspect that still presents challenges. The integration of Pyro4 to facilitate communication between agents has proven to be a key tool in this process, enabling efficient and secure communication. This implementation proposed in this study is a preliminary proposal for a lightweight and secure agent platform that can be adapted to be compatible with more efficient communication mechanisms such as gRPC—a high-performance mechanism that uses Protocol Buffers and HTTP/2, achieving much faster communication than traditional JSON/XML-based approaches like REST [22].

The multi-level security scheme implemented in the architecture, combining symmetric, asymmetric, and hybrid encryption along with TOTP-based authentication, has been effective in ensuring the confidentiality and integrity of data. This approach provides adequate protection of information in a distributed environment where agents interact in real time. A qualitative comparison of our approach with the current approaches that use embedded agents for controlling IoT is described in

Table 4. Comparative of the proposal with other existing approaches that embed agents for controlling the IoT.

Approach/Architecture	Used Technology	Cybersecurity Mechanisms	Authentication Mechanisms	Scenario	Embedded Agents	Adaptability
sabIoT: proactive embedded agents in IoT devices [8]	osBrain, Pyro4, ØMQ, Python, Raspberry Pi 4, Grove Pi+	N/A	Trust network + Nameserver (yellow pages)	Smart Homes (climate, comfort, CO2)	Yes	Very high: agents detect devices/services in the network, adapt and collaborate dynamically
ROS2 agents with multitasking and hierarchical behavior [10]	ROS2, DDS, Python 3, Gazebo, asyncio	N/A	N/A	Industrial intralogistics (EMILI vehicle)		High: tested in simulations and physical robot; concurrent execution of actions without errors
Embedded BDI agents [7]	ROS, Jason, ROSJava, Python, Raspberry Pi, Beagle Bone	N/A	N/A	Robotics, UAVs, search and rescue	Yes	High: distributed, standardized, reusable architecture; supports heterogeneous hardware with minimal reprogramming
Embedded BDI agents [11]	Jason, Java, Raspberry Pi 3, BrickPi, LEGO sensors, EV3 API	N/A	N/A	Smart production line	Yes	High: Modular architecture, platform-independence, adaptable to the environment with reactive and proactive reasoning
Embedded BDI fuzzy agents [12]	Jason, FIS, Java, Raspberry Pi, LEGO sensors	N/A	N/A	Intelligent production line	Yes	Very high: Agents dynamically reconfigure behavior; highly customizable via fuzzy rules
Agent with embedded logic [13]	Arduino, Raspberry Pi 3, Zigbee, Python, Qt5, Aquacrop, MySQL	N/A	N/A	Precision agriculture (onion irrigation)	Yes	Very high: Modular system, editable rules, adaptable to various crops, sensors, and irrigation infrastructures
IoT-MAS with fuzzy logic [15]	Fuzzy logic, IoT, MAS agents (AoT, FA, LCA, GCA), IoT protocols (MQTT, TCP/IP)	N/A	N/A	Smart city	Yes	Very high: Modular, scalable architecture, adaptable according to BSL/ASL pattern and environmental conditions
IoST: Smart Things embedded with specialized agents [16]	Jason, Raspberry Pi Zero, ATMEGA328, ContextNet, Galileo Gen2	Local autonomy in case of network failure, robustness against disconnections	Agent identification via ContextNet	Smart environments (climate, energy, comfort, automation)	Yes	Very high: Modular architecture, agents configurable by type, full adaptability to hardware and domain
LightGuardAgents (our proposal)	osBrain, Pyro4, Python, Raspberry PI	Daemon of Nameserver Gateway manager Encryption and decryption of messages	TOTP Private and public key	Embedded systems	Yes	Very high: Modular architecture, allowing for dynamic agent registration and direct inter-agent communication. It also provides robust support for heterogeneous devices and exhibits partial fault tolerance

. However, key management and the authentication process can be complex for users without technical expertise, suggesting the need to simplify these processes in future versions of the architecture to improve accessibility and facilitate adoption in large-scale applications.

The comparative analysis of the published proposals that put forth lightweight embedded agents for IoT, described in Table 4, reveals that most embedded multi-agent architectures oriented toward the IoT focus primarily on specific functions, such as lighting control, precision agriculture, or cyber-physical systems. However, explicit consideration of security aspects—such as encryption, authentication, or access control—is either limited or altogether absent. In many cases, these solutions operate under the assumption of deployment in closed environments or trusted networks, which limits their scalability and applicability in more open and vulnerable contexts, such as smart cities. In contrast, the LightGuardAgents architecture is introduced as a lightweight, distributed, and security-centered solution that integrates robust protection mechanisms, including hybrid encryption, TOTP-based authentication, and access control via whitelists and blacklists, designed specifically for operation in potentially adversarial environments.

Regarding performance, it is observed that most existing proposals rely on functional or qualitative validation, often lacking precise metrics on resource consumption, response times, or operational efficiency. A notable exception is the body of work by Karaduman, which includes comparative studies between development frameworks such as Jason and Jade, as well as fuzzy logic-based optimization techniques. In this context, LightGuardAgents, while still in the qualitative validation phase, introduces a solid foundation for evaluation through a set of functional metrics (SM1–SM20). These metrics enable structured assessment of system capabilities and establish a potential baseline for future standardized evaluations.

The performance metrics used in this study (SM1–SM20) are intentionally defined to capture the most relevant operational aspects of embedded multi-agent systems in IoT environments. In particular, these metrics reflect the computational overhead, security enforcement cost, and coordination efficiency introduced by the proposed architecture. Metrics such as agent registration time, authentication latency, encrypted communication overhead, service discovery delay, and fault tolerance behavior are directly related to CPU usage, memory consumption, and energy expenditure, which are critical constraints in resource-constrained IoT devices. Rather than focusing on statistical accuracy, learning-based indicators, or large-scale stress testing, the selected metrics validate that the integrated security mechanisms do not impose prohibitive delays or operational bottlenecks. This makes the metric set suitable for assessing the correct operation and architectural robustness of the proposed system, which is the primary objective of the experimental validation.

Recent research on zero-sample and out-of-distribution detection, such as the Shrinkage Mamba Relation Network proposed by Chen et al. [23], has demonstrated promising results in data-driven fault diagnosis under scenarios with limited or unavailable faulty data. Similar advances have been reported in industrial cyber–physical systems through clustering-based and representation learning approaches designed to generalize under unseen operating conditions [24]. These methods are particularly relevant in industrial monitoring contexts, where labeled fault data are scarce or costly to obtain. However, such approaches rely on machine learning models, training processes, and statistical generalization mechanisms, which differ fundamentally from the architectural focus of the present work. LightGuardAgents does not perform fault detection or anomaly classification through learned models; instead, it provides a secure and lightweight agent-based architecture aimed at enabling reliable interaction, coordination, and protection mechanisms in distributed IoT environments. While data-driven detection techniques could be integrated as agent-level services in future extensions, they are beyond the scope of the current architectural validation.

The proposed architecture does not rely on tunable model parameters in the sense of data-driven or machine learning approaches. Instead, it employs operational security parameters defined by widely adopted standards and architectural design choices. For instance, the TOTP-based authentication mechanism follows standard time-window configurations, and cryptographic mechanisms are selected according to established best practices. As a result, a traditional parameter sensitivity analysis is not applicable in this context, since the evaluation focuses on validating the correct integration and operation of the architectural components rather than optimizing parameter values.

With respect to time-based authentication, the architecture relies on TOTP mechanisms, which inherently tolerate limited clock drift through the use of standard validation time windows. In this context, LightGuardAgents assumes that participating devices maintain a basic level of time synchronization, as commonly provided by the underlying operating system, gateway devices, or lightweight synchronization mechanisms available in IoT environments. The architecture does not impose a specific time synchronization protocol in order to preserve its lightweight and technology-independent nature. When clock divergence exceeds the acceptable validation window, authentication requests are rejected as a protective measure, and agents must reattempt registration once time synchronization is restored. This behavior reinforces security while maintaining low computational overhead on resource-constrained devices.

To further contextualize the proposed approach, a comparative analysis is provided between LightGuardAgents and representative communication and security solutions commonly adopted in IoT environments, including gRPC with mutual TLS [25] and MQTT with TLS/SASL [26]. Although a full quantitative performance benchmark is outside the scope of this work, the comparison focuses on objectively defined security and performance-related attributes—such as authentication mechanisms, key management complexity, communication overhead characteristics, and suitability for resource-constrained devices—based on official specifications and established standards. This analysis, summarized in

Table 5. Qualitative comparison between LightGuardAgents and representative IoT communication and security approaches.

Aspect	LightGuardAgents	gRPC + mTLS	MQTT + TLS/SASL
Communication model	Agent-based, peer-to-peer with directory-assisted discovery	Client–server RPC over HTTP/2	Publish/subscribe via broker
Security integration	Native, embedded into agent lifecycle	External, enforced by TLS layer	External, enforced by TLS/SASL
Authentication mechanism	TOTP-based authentication + whitelist/blacklist	Mutual TLS with X.509 certificates	Username/password, certificates, or SASL
Key management	Decentralized, agent-generated keys; directory-assisted exchange	PKI-based certificate management	Certificate-based or broker-managed credentials
Dependency on PKI	Not required	Required	Typically required
Clock synchronization requirement	Required within TOTP validation window	Not required	Not required
Overhead on constrained devices	Low, event-driven key management	Moderate to high due to TLS handshake	Moderate due to broker and TLS overhead
Scalability model	Distributed agent discovery via Yellow Page	Centralized service endpoints	Broker-centric scalability
Fault tolerance	Agent-level isolation and revocation	Service-level	Broker-dependent
Suitability for resource-constrained IoT	High	Limited	Medium
Primary validation focus	Architectural and security behavior	Performance and interoperability	Messaging reliability

, allows an informed assessment of trade-offs without introducing additional experimental assumptions beyond the validated architecture.

As summarized in Table 5, existing solutions such as gRPC with mTLS and MQTT with TLS/SASL provide strong security guarantees at the transport or broker level but typically rely on external infrastructures, centralized trust models, or heavyweight configuration processes. In contrast, LightGuardAgents adopts a security-centered architectural approach in which authentication, key exchange, and access control are embedded directly into the agent lifecycle. This design enables secure agent coordination in open IoT environments while preserving lightweight deployment and reduced dependency on centralized PKI or broker-centric mechanisms.

Finally, it is important to emphasize that security is not merely an added feature in LightGuardAgents but rather a core principle embedded within the architectural design. Unlike other approaches in which security mechanisms arise as byproducts of functional requirements, this architecture treats security as a transversal and explicitly defined property. This design perspective positions LightGuardAgents as an original and relevant contribution within the domain of embedded MAS architecture, particularly in applications where information protection and access control are critical system requirements.

Despite the promising results obtained, the proposed architecture presents several limitations that must be acknowledged. First, the validation was conducted through a representative case study, which, while sufficient to demonstrate feasibility and integrated security behavior, does not encompass all possible IoT deployment scenarios or adversarial conditions. Second, the architecture exhibits partial dependency on central components such as the Nameserver and Yellow Page, which may represent single points of failure under prolonged service outages or large-scale deployments. Although partial fault tolerance was observed, full resilience mechanisms—such as replicated directories, consensus-based coordination, or Byzantine fault tolerance—are not currently implemented. Additionally, the experimental evaluation focuses on architectural correctness and security integration rather than exhaustive performance optimization or stress testing; therefore, absolute performance figures may vary depending on hardware capabilities, network conditions, and execution platforms. These limitations define clear directions for future work, including large-scale evaluations, enhanced fault tolerance, and broader comparative studies with alternative middleware and agent frameworks.

6. Conclusions and Future Directions

In this research, we have developed and evaluated an architecture for creating multi-agent systems in the context of IoT, using Pyro4 to facilitate efficient and secure communication between autonomous agents. Within the scope of the experimental validation conducted through the presented case study, the proposed architecture addresses common challenges in distributed systems, such as data security and coordination among autonomous devices. The architectural design, which incorporates components such as the Yellow Page, Nameserver, Nameserver Daemon, and Gateway Manager, demonstrates its ability to support secure and coordinated interactions between agents in a distributed environment.

Based on the results obtained from the case study, the proposed architecture demonstrates that a multi-level security scheme—combining symmetric, asymmetric, and hybrid encryption with TOTP-based authentication—can be effectively integrated into embedded agent systems without introducing significant temporal overhead. Quantitative results show that the majority of agent operations, including registration, authentication, service discovery, and secure communication, were completed within a few milliseconds, with median execution times below 0.001 s and more than 75% of operations completing under 0.002 s. These results indicate that the security mechanisms imposed by the architecture are compatible with the timing constraints of resource-constrained IoT devices.

Overall, the architecture presented in this study represents a promising approach for secure multi-agent systems in IoT environments. While the experimental validation is limited to a representative use case, the observed low-latency behavior and stable operation under dynamic conditions suggest that the proposed approach is suitable for deployment in environments where computational resources, energy consumption, and communication efficiency are critical requirements. Future work will focus on extending the evaluation to larger-scale deployments, exploring alternative communication mechanisms such as gRPC to improve interoperability, and enhancing usability by simplifying configuration processes and facilitating integration with emerging technologies.