Uli SDK - an advanced software framework designed to integrate and orchestrate assets and their capabilities across multiple operational domains. Building on its fundational interoperability, the Uli SDK empowers the LLM-based applications by providing them with crucial, real-world context from the connected ecosystem, through consistent interfaces to agents (for action and control) and data topics (for states and status).

To ensure the security of the operation, the Uli SDK implements a robust server-client authentication and authorization framework that distinctly governs data and control access. The framework enforces the security by requiring clients to initiate distinct requests for data access and control access. For each request, the client must present a valid certification. Upon successful validation, the server grants a tailored set of permissions and issues a corresponding session token: either a data access uuid for data requests or a control access uuid for control requests. The client must then use the data access uuid to subscribe to data topics and the control access uuid to request exclusive control of agents.

To further fortify the security of an established session, the framework enforces a strict session lifecycle management policy. To maintain an active connection, clients are required to periodically resubmit their session uuid to the relevant data or agent servers, acting as a "keep-alive" mechanism that prevents the session from expiring due to inactivity. Furthermore, each session uuid is designed with a finite lifetime. The system automatically generates a new uuid after a predefined period, invalidating the old one. This dual-pronged approach of session timeouts and periodic rotation significantly enhances security by minimizing the attack window for potential session hijacking and ensuring that any compromised token becomes useless in a short amount of time.

This access control model is scoped at the subsystem level, governing how client subsystems interact with the data and agents of other subsystems. A fundamental distinction is made between the two types of access. Data access is designed as a shared, one-to-many relationship, permitting multiple client subsystems to concurrently subscribe to data topics from a single source. In stark contrast, control access is strictly exclusive. This one-to-one relationship ensures that only a single client subsystem can be granted the privilege to operate the agents of a target subsystem at any given time, preventing conflicting commands and ensuring operational stability. The following sections will examine the specific implementation details of this architecture.

Data Access

The management and enforcement of data access are centralized within the Subsystem Access service. This service implements a hierarchical permission model to categorize access rights, granting clients privileges in one of three tiers: Classified, Controlled, and Unclassified. In this model, Classified represents the highest level of privilege, while Unclassified constitutes the lowest. Each client is assigned a specific access right upon successful authentication, which dictates the scope of data they are permitted to view.

This classification system is fundamental to the framework's data segregation capabilities. When a client with a granted access level attempts to subscribe to data, the framework automatically filters the available data topics, presenting only those that match or fall below the client's authorized privilege level. For example, a client with Controlled access will be able to see both Controlled and Unclassified topics, but will be completely unaware of any topics designated as Classified.

The precise event sequence for a client requesting and being granted data access is detailed below.

Control Access

Control access is managed by the dedicatedSubsystem Control service and is designed to be fundamentally exclusive, ensuring that only one client can operate a subsystem's agents at any given time. This exclusivity is enforced through a preemption model based on a numerical authority code, which ranges from 1 (lowest) to 255 (highest). If a new client requests control while another is already active, the service will grant access to the client with the higher authority code, automatically revoking the session of the incumbent client.

Upon receiving a control request authenticated by a certificate, the Subsystem Control service notifies the client whether the request has been granted or denied. If granted, the service assigns a specific access right from one of three privilege tiers: Operator, Maintainer, and Administrator, with Administrator being the highest. Mirroring the data access model, this granted right is used to filter the available agents. The controlling client is only presented with, and can only interact with, agents that correspond to its authorized privilege level, preventing unauthorized operations.

The event sequence for a client requesting and being granted control access is detailed below.