# Zero trust architecture

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

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

[CONTACT](/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.

```
%%{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](/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.

```
%%{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](/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/identity-and-authentication/)
- [Connectors](/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/connectors/)
- [Policies and permissions](/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/policies-and-permissions/)
- [Audit and diagnostics](/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/audit-and-diagnostics/)
- [End-user experience](/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)