Project Deliverable: Secure Agent Discovery Model for a Smart Home Network

1. Chosen Scenario: Smart Home Network

In this scenario, a multi-agent system manages a modern smart home. The system consists of various autonomous software agents, each responsible for a specific function. These agents run on different devices within the home (e.g., a central hub, smart speakers, dedicated microcontrollers) and may also connect to external cloud services.

The key agents and their roles are:

- Lighting Agent: Manages smart bulbs based on occupancy and time of day.
- Climate Agent: Controls the HVAC system, optimizing for comfort and energy efficiency.
- Security Agent: Monitors door/window sensors, motion detectors, and security cameras. It can trigger alarms and notify the homeowner.
- Energy Management Agent: Monitors the home's overall energy consumption and coordinates with the grid or solar panels.
- User Interface Agent: Manages the primary mobile app or voice interface, accepting commands and providing status updates.

The primary challenge is that these agents need to discover each other dynamically. For instance, the Security Agent needs to find and authenticate the User Interface Agent to send alerts. A new smart bulb, and its corresponding Lighting Agent, must be able to join the network and be discovered by the central system without manual configuration.

2. The Agent Naming and Discovery Model (ANS Model)

The model is composed of three core functions: Naming, Addressing, and Discovery.

a) Naming (How are agents named?)
The naming scheme uses a structured, human-readable but hierarchical format.
- Format: `[service-type].[home-identifier].[unique-instance-id]`
- Example: `lighting.main-home.01`
    - `lighting`: Defines the service or function (type) of the agent.
    - `main-home`: The identifier for this specific smart home environment. This ensures agents from different homes are segregated.
    - `01`: A unique identifier for this specific instance (in case of multiple lighting agents in a large home).
This hierarchical approach allows for easy filtering, routing, and management.

b) Addressing (How are agents located on the network?)
Agents are addressed at two levels:
- Logical Addressing: The `service-type` and `home-identifier` are used by the discovery service to find the appropriate agents. For direct communication, agents use the underlying network address (IP address and port).
- Physical Addressing: The system maintains a dynamic mapping between an agent's logical name (e.g., `lighting.main-home.01`) and its current physical network address (e.g., `192.168.1.50:8080`). This is handled by a central, secure registry. This decouples the agent's logical identity from its physical location, allowing agents to move between networks or devices seamlessly.

c) Discovery (How do agents find each other?)
The discovery process relies on a hybrid approach combining a central registry with a peer-to-peer heartbeat mechanism for resilience.

- Central Registry: A secure, authenticated "Directory Service" agent runs on a trusted device in the home (e.g., the smart home hub). All agents must register with this service upon startup.
- Heartbeat Protocol: All registered agents send a periodic "heartbeat" message to the registry to confirm they are active. The registry maintains a list of "active agents." If a heartbeat is missed, the agent is marked as inactive and the registry notifies any subscribed agents.
- Subscribe & Query: Other agents, like the User Interface Agent, can query the registry to find a service. For example, to control the lights, the UI Agent sends a query to the registry: `find(service-type=lighting)`. The registry responds with a list of all active agents of that type.
- Direct Discovery (P2P Fallback): If the central registry becomes unavailable, agents can fall back to a multicast discovery mechanism on the local network. They will broadcast a query for a specific service type. This ensures the system remains partially functional even if the central hub fails.

3. Security Measures

Security is embedded into every stage of the discovery process to prevent spoofing and unauthorized access.

- Mutual Authentication with X.509 Certificates:
    - Every agent is provisioned with a unique digital certificate from a trusted Certificate Authority (CA) during manufacturing or initial setup.
    - When an agent first connects to the registry, a mutually authenticated TLS (mTLS) handshake is performed. Both the agent and the registry verify each other's certificates.
- Registry Authorization:
    - The registry maintains an Access Control List (ACL). An agent can only register if its certificate is valid and its `service-type` is authorized for the `home-identifier`.
    - For example, a new camera (Security Agent) will be authorized, but a random laptop trying to impersonate a Lighting Agent will be rejected.
- Encrypted Communication:
    - All communications between agents and the registry, and all subsequent peer-to-peer messages between agents, are encrypted using TLS.
- Secure Name Verification:
    - A critical check is performed to ensure that the name an agent presents at registration matches the identity in its certificate. This prevents an attacker from stealing a certificate and registering with a different, misleading name (e.g., stealing the certificate of a Climate Agent but trying to register as a Security Agent).
- Heartbeat Saturation:
    - This is a defense against Denial of Service (DoS) attacks. The registry limits the rate of heartbeat messages from any single agent. A flood of registration attempts is also rate-limited.

4. Distribution and Scalability

The system is designed to scale efficiently across nodes and networks using a tiered architecture.

- Tier 1: Local Home Network: This is the primary, low-latency tier for all core smart home functions. The central registry and all local agents operate here. This tier handles the majority of discovery requests.
- Tier 2: Cloud Backend and Federated Hubs: For large, multi-building estates or for integration with smart city infrastructure, the system can scale.
    - Agent Hierarchy: Agents are organized hierarchically. A local registry in each building (main-home, guest-house) only manages agents within that building. A top-level "Site Registry" in the cloud can discover and communicate with the local registries.
    - Scaling Strategy:
        1. Vertical Scaling: The local registry, if running on a capable hub, can be assigned more CPU and memory resources to handle hundreds of agents.
        2. Horizontal Scaling (Federation): The system's primary scaling method is federation. When a home becomes too large, it can be logically segmented (e.g., by floor or by function). Each segment gets its own registry (a "Sub-Registry"). These sub-registries register themselves with a master registry. This distributes the load.
        3. Caching: Agents heavily cache discovery results locally. For example, the Lighting Agent will remember the address of the User Interface Agent after the first discovery, reducing the load on the registry.
- Cross-Network Discovery:
    - For an agent outside the local network (e.g., the homeowner's mobile app on 5G), the system uses a secure relay and the cloud backend. The mobile app authenticates with the cloud, which then acts as a proxy to securely route queries to the relevant local home registry.

5. Flow Diagram of the Agent Discovery Process

The following is a textual representation of the agent discovery process, showing a new agent joining the network and another agent finding it.

+-----------------------------------------------------------------------------------------------------------------+
|                         SECURE AGENT DISCOVERY PROCESS - SEQUENCE DIAGRAM                                      |
+-----------------------------------------------------------------------------------------------------------------+

Agent A (New)           Directory Service (Registry)       CA Infrastructure       Agent B (UI Agent)
    |                           |                                  |                         |
    |  1. mTLS Handshake        |                                  |                         |
    |-------------------------->|                                  |                         |
    |  (ClientHello, Cert)      |                                  |                         |
    |                           |  2. Certificate Validation       |                         |
    |                           |--------------------------------->|                         |
    |                           |                                  |  3. Cert Valid          |
    |                           |<---------------------------------|                         |
    |  4. mTLS Handshake OK     |                                  |                         |
    |<--------------------------|                                  |                         |
    |                           |                                  |                         |
    |  5. Registration Request  |                                  |                         |
    |  (Name: lighting.home.01) |                                  |                         |
    |-------------------------->|                                  |                         |
    |                           |  6. Verify Name vs. Cert         |                         |
    |                           |  & Check ACL                    |                         |
    |                           |                                  |                         |
    |  7. Registration Success  |                                  |                         |
    |<--------------------------|                                  |                         |
    |  (Token/Ack)             |                                  |                         |
    |                           |                                  |                         |
    |  8. Periodic Heartbeat   |                                  |                         |
    |-------------------------->|                                  |                         |
    |                           |                                  |                         |
    |                           |                                  |  9. Query Request        |
    |                           |                                  |  (find service: lighting) |
    |                           |                                  |<-------------------------|
    |                           |                                  |                         |
    |                           |  10. Query Processing            |                         |
    |                           |  (Find active agent)            |                         |
    |                           |                                  |                         |
    |                           |  11. Query Response             |                         |
    |                           |  (Address of lighting.home.01)  |                         |
    |                           |--------------------------------->|                         |
    |                           |                                  |                         |
    |                           |                                  |  12. Direct mTLS Comm   |
    |                           |                                  |   (UI Agent <-> New Agent)|
    |                           |                                  |------------------------->|
    |                           |                                  |                         |

+-----------------------------------------------------------------------------------------------------------------+
| EXPLANATION OF EACH STEP:                                                                                       |
|                                                                                                                 |
| 1-4: The connection is secured with mutual authentication, ensuring both parties are trusted.                    |
| 5-7: The new agent registers its logical name. The registry validates the name against the certificate identity  |
|      and checks the ACL to ensure the agent is allowed in this network.                                         |
| 8: The new agent sends a heartbeat to signal it's active.                                                       |
| 9-10: A user interface agent queries the registry for a 'lighting' service.                                     |
| 11: The registry returns the network address (IP:Port) of the newly registered lighting agent.                  |
| 12: Agents now communicate securely, with the registry acting as the trusted source of truth for the initial   |
|     discovery. All future communications are peer-to-peer but remain encrypted.                                 |
+-----------------------------------------------------------------------------------------------------------------+