# Zero trust architecture

- Link: https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/zero-trust-architecture/
- Published: 2026-08-24T01:47:08+00:00
- Author: Don Bowman

1. [Home](https://www.agilicus.com/)
 2. [Agilicus AnyX Administrative Web Interface](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/)
 3. [Concepts](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/)
 4. Zero trust architecture

![3a77b44a-featured-anyx-admin-conceptszero-trust-architecture](https://www.agilicus.
com/www/3a77b44a-featured-anyx-admin-conceptszero-trust-architecture.png)

## Zero trust architecture

[CONTACT](https://www.agilicus.com/contact-us/)

Agilicus AnyX implements a **zero trust architecture**: no device, user, or network
is trusted by default. Every access request is authenticated and authorised individually,
regardless of where the request comes from.

The practical consequences for an administrator are:

 * your resources have **no inbound ports** and are not discoverable from the internet;
 * users are identified by **who they are**, not by where they connect from;
 * access decisions are made **per request**, against policy, in real time; and
 * every decision and every session is **recorded** for audit.

## Theory of operation

The platform relies on a few moving parts:

 * a **CNAME** at your own domain that points at the Agilicus service, so the platform
   can serve content under a name you control;
 * **connectors** that run outbound from your site to the Agilicus cloud;
 * an **identity-aware proxy** in the cloud that terminates user sessions, applies
   policy, and forwards traffic over the outbound-only tunnel; and
 * **identity providers** that authenticate your users.

    ```wp-block-agilicus-mermaid
    %%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
    flowchart LR
        subgraph Internet
            U[User]
            IDP[Identity provider<br/>Google, Microsoft, etc.]
        end
        subgraph Cloud["Agilicus cloud"]
            AP[Identity-aware proxy]
            AP2[Authorisation engine]
        end
        subgraph Site["Your site"]
            C[Connector]
            R1[Web application]
            R2[Database]
            R3[Desktop]
        end
        U -->|HTTPS via CNAME| AP
        U -->|sign in| IDP
        IDP -->|verification| AP
        AP --> AP2
        AP2 -->|allowed| C
        C -->|outbound-only tunnel| AP
        C --> R1
        C --> R2
        C --> R3
    ```

Notice the direction of the arrows: the connector reaches **out** to the cloud. 
Nothing reaches in. This is what removes the need for inbound port forwarding, port
forwarding rules, and public internet exposure.

## The CNAME and your domain

Your organisation is given a domain name (for example `org.agilicus.com`) and you
point a CNAME record at it from a name you control. Users then access the platform
and resources through that name. This matters because:

 * it gives you a stable, branded entry point;
 * TLS certificates are issued for your name;
 * the platform can host resources on subpaths of your domain; and
 * it lets you move the underlying infrastructure without changing the name users
   rely on.

## Outbound-only connectors

A connector is a small piece of software installed on your side of the network (
on a virtual machine, a container, a router, or an embedded device). It maintains
one or more **outbound** connections to the Agilicus cloud. The cloud never initiates
connections to you. This design means:

 * your firewalls do not need inbound rules for the platform;
 * resources behind the connector are invisible to the public internet; and
 * the connector works on almost any network, including carrier-grade network address
   translation.

See [Connectors](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/connectors/)
for deployment options and management.

## The identity-aware proxy

The identity-aware proxy is the component in the cloud that:

 1. terminates the user’s HTTPS session;
 2. authenticates the user (directly or through an identity provider);
 3. enforces multi-factor authentication when policy requires it;
 4. evaluates authorisation for the specific resource being requested;
 5. applies any firewall and geolocation rules; and
 6. forwards the request to the correct connector, which reaches the resource.

Because each request passes through this proxy, the platform can apply per-user,
per-resource policy and record exactly what happened.

    ```wp-block-agilicus-mermaid
    %%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
    stateDiagram-v2
        [*] --> Authenticated: user signs in
        Authenticated --> Authorised: policy allows resource
        Authenticated --> Denied: policy denies resource
        Authorised --> Forwarded: routed to connector
        Forwarded --> Served: connector reaches resource
        Served --> Audit: request recorded
        Denied --> Audit: denial recorded
        Audit --> [*]
    ```

## Security properties

 * **Encryption in transit.** All traffic uses HTTPS with TLS 1.3. Nothing is sent
   in the clear.
 * **Identity over network.** Access is granted to the person, not to the network
   segment they happen to be on.
 * **Least privilege.** You can grant read-only or very narrow access to a single
   application, down to a specific role within it.
 * **No attack surface.** With no inbound ports, there is nothing for an attacker
   to scan or connect to.
 * **Full audit trail.** Every request, decision, and session is logged and can 
   be sent to your own log destination.

## Further reading

 * [Identity and authentication](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/identity-and-authentication/)
 * [Connectors](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/connectors/)
 * [Policies and permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/policies-and-permissions/)
 * [Audit and diagnostics](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/audit-and-diagnostics/)
 * [End-user experience](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/end-user-experience/)

## Web guide

 * [Theory of operation: CNAME + DOMAIN](https://www.agilicus.com/product-guide/theory-of-operation-cname-domain)
 * [Access an internal resource with no inbound connections](https://www.agilicus.com/access-an-internal-resource-with-no-inbound-connections)
 * [Zero trust architecture (NIST)](https://www.agilicus.com/zero-trust-architecture-published-by-nist)
 * [About the CNAME](https://www.agilicus.com/about-dns-cname)