Trust Service Constructs Overview

The Nile Trust Engine enforces access decisions for each flow based on a structured and consistent policy framework that applies to all endpoint types, without requiring agents. This framework defines how users, devices, and applications are classified, grouped, and governed under the principles of Zero Trust. Every communication request passes through a sequence of constructs that determine whether access is allowed, denied, or redirected.

The Trust Engine relies on several key constructs that work together to deliver comprehensive and scalable policy enforcement:

Policy Groups are the foundation of the Trust Engine. They allow administrators to define security boundaries around users, devices, or applications based on identity, context, or network characteristics. Policy groups are used in defining access policies, either as a source or as a destination.

Nile’s Zero Trust policies layer is decoupled from networking segments. While traditional approaches use VLANs and network segments as a means to define security boundaries, NIle allows policy groups to be completely identity based. Any user or device can obtain an IP from any network segment, while their access policy can be purely based on identity and context.  With identity-based policy groups, segmenting devivces using network segments is unnecessary - all enterprise endpoints can reside in a single subnet and still be securely isolated with traffice governed by least-privilege access policies.

For customers who still desire to segment endpoints using network segments, whether for organizational or operational/interworking purposes, or to support multiple authentication methods, Nile fully supports policy groups that map to network segments. 

Each endpoint is classified into exactly one policy group. When multiple groups apply, the most specific rule (based on ordering) takes precedence.

The process of classifying endpoints occurs after an endpoint has obtained its IP address and has completed the network on-boarding process. Once on-boarded, endpoints are classified into a policy group based on evaluation priority. User group definitions are checked first, followed by device groups. More specific classification groups should be placed higher in the list to ensure correct matching.

If an endpoint does not match any defined policy group, it is automatically placed into the Unclassified policy group, where they can then be manually assigned. Devices that fail continuous device validation checks are placed in the Quarantine policy group.

Nile provides predefined groups to simplify policy creation:

These groups are automatically recognized by the Trust Engine and appear in the policy interface as selectable sources or destinations.

Unlike traditional VLAN-based security, Nile’s policy groups can be identity-driven. This means users and devices can share the same IP segment while maintaining strict isolation through host-based controls. This approach simplifies network design and reduces the need for static segmentation.

Service Profiles define which protocols and ports are permitted when traffic between policy groups is allowed. They ensure communication adheres to least-privilege principles by restricting flows to only what is necessary. Service profiles are mandatory for any policy that is configured to allow or forward traffic - this is consistent with Zero Trust principles. Rules within a service profile are ordered, and the default rule is to exclude any port and any protocol (i.e., "deny all ports/protocols").

For a printer, different functions (discovery, printing, administration) use distinct ports and protocols. A service profile can be used to allow employees to discover printers and send print jobs only, and restrict access to administrative interfaces. WIth servicei profiles, precise access can be granted based on role.

Custom Service Profiles are available to Enterprise Trust Service customers, providing fine-grained control over protocol-level access.

An Action determines how a flow is enforced within an access policy. Every flow is inspected by the centralized policy engine and the resuling action is logged in the policy log, detailng how the flow was treated.



A Policy Set is a collection of policies that together define how access is managed within the network. Each policy specifies a source, destination, service profile, and action.

All network traffic is evaluated against the active policy set. If no matching policy exists, the traffic is denied by default.

Each Nile tenant includes one Global Policy Set, automatically applied to all sites. It contains system-defined defaults that ensure essential network operations, such as DNS resolution and DHCP onboarding, function without manual setup.

Administrators can add custom policies to the Global Policy Set to reflect organizational requirements. Future releases may include support for multiple policy sets per tenant for more granular control.

Every flow evaluated by the Trust Engine generates a log entry visible in Nile Control Center. Logs include:

These logs enable administrators to audit policy effectiveness, identify unauthorized attempts, and refine enforcement strategies.

The Trust Engine’s constructs—policy groups, service profiles, policy sets, and actions - form a unified framework for implementing zero trust across enterprise networks. By classifying endpoints through identity and context rather than topology, Nile delivers precise, scalable, and adaptable security enforcement.

Next: Policy Group Management — Learn how to create, classify, and manage policy groups for users, devices, and applications.