> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usetero.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Architecture

> End-to-end security architecture, trust boundaries, and enforcement model.

export const securityEmail = "security@usetero.com";

<Badge>Last reviewed: March 5, 2026</Badge>
<Badge>Owner: Security + Engineering</Badge>
<Badge>Review cadence: Quarterly</Badge>
<Badge color="green">Status: Implemented</Badge>

This page maps request flow through Tero, the trust boundaries along the way, and the controls that enforce them.

## Reviewer focus

* Where authentication, authorization, encryption, and logging controls are enforced
* Where Tero terminates traffic and whether it requires inbound connectivity
* Which architecture layers are Tero-owned vs customer-owned in self-hosted deployments

## Implementation status (March 5, 2026)

Tero operates as a control plane. Customer users and systems call Tero APIs over HTTPS. Tero executes operations within tenant and workspace scope and logs security-relevant activity for audit and response.

## System flow diagram (hosted default)

```mermaid theme={null}
flowchart LR
    U[Customer Users] --> E[Cloudflare Edge]
    I[Customer Integrations] --> E
    E --> A[Auth + Session Validation]
    A --> Z[Tenant/Workspace Authorization]
    Z --> C[Tero Control Plane]
    C --> D[(Encrypted Control-Plane Data Stores)]
    C --> L[(Security + Audit Logs)]
    C -. Optional provider path .-> P[AI Provider Integration]
```

## End-to-end request flow (hosted default)

1. A user or integration authenticates to approved endpoints.
2. Traffic reaches Tero over TLS-protected connections.
3. Tero authorizes requests to tenant and workspace scope.
4. Services execute control-plane workflows and metadata processing.
5. Tero stores required data in encrypted managed services.
6. Tero records security and operational events for detection and audit.

## Trust boundaries and enforcement points

| Boundary    | What it separates                                                | Key controls                                                             |
| ----------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Identity    | Authenticated users and integrations vs unauthenticated requests | Auth provider integration, token and session validation, scoped access   |
| Network     | Internet edge vs application ingress                             | TLS-required connections, edge protections, controlled endpoint exposure |
| Application | Tenant and workspace operations                                  | Tenant-scoped authorization and role-based access patterns               |
| Data        | Control-plane metadata vs customer source telemetry systems      | Data minimization model and bounded storage scope                        |
| Secrets     | Runtime services vs credential material                          | Managed secret stores with least-privilege access                        |

## Tenant isolation model (hosted)

| Layer       | Isolation approach                                                                                                                  |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Application | Tero authorizes requests in tenant and workspace scope; role and operation checks run before execution                              |
| Data        | Tero applies tenant and workspace context in control-plane data access paths; bounded data model reduces cross-tenant exposure risk |
| Network     | Managed ingress and service boundaries isolate Internet edge, application ingress, and internal service communication paths         |

## Isolation boundary diagram

```mermaid theme={null}
flowchart TB
    subgraph Identity_Boundary[Identity Boundary]
        AUTH[Authenticated User/Session or Integration Token]
    end

    subgraph Network_Boundary[Network Boundary]
        EDGE[Internet Edge + Ingress Controls]
    end

    subgraph Application_Boundary[Application Boundary]
        APP[Tenant/Workspace Authorization Layer]
    end

    subgraph Data_Boundary[Data Boundary]
        META[(Control-Plane Metadata Stores)]
        SRC[(Customer Source Telemetry Systems)]
    end

    subgraph Secrets_Boundary[Secrets Boundary]
        SEC[Managed Secret Store with Scoped Access]
    end

    AUTH --> EDGE --> APP --> META
    APP -. no baseline vendor-initiated inbound connectivity .-> SRC
    APP --> SEC
```

## Architecture diagrams and review artifacts

Tero maintains architecture documentation that describes trust boundaries, tenant isolation, and data-flow separation. This Trust Center includes public overview material; Tero shares deeper architecture walkthrough material for security review under NDA.

## Traffic and termination model

| Path                                           | Tero-hosted                               | Self-hosted                        |
| ---------------------------------------------- | ----------------------------------------- | ---------------------------------- |
| External API traffic                           | HTTPS to Tero-managed endpoints           | Customer-defined ingress path      |
| TLS termination                                | Hosted edge reverse-proxy layer           | Customer-defined termination model |
| Service-to-service traffic                     | Managed cloud networking controls         | Customer networking controls       |
| Inbound connectivity into customer environment | Not required for baseline API integration | Customer-controlled                |

## Hosted vs self-hosted ownership

| Area                                         | Tero-hosted                 | Self-hosted                     |
| -------------------------------------------- | --------------------------- | ------------------------------- |
| Infrastructure runtime ownership             | Tero                        | Customer                        |
| Environment hardening                        | Tero platform controls      | Customer environment controls   |
| Secrets backend operations                   | Tero-managed implementation | Customer-managed implementation |
| Private connectivity model                   | Tero-managed hosted model   | Customer-defined                |
| Incident ownership for infrastructure events | Tero                        | Customer                        |

## Evidence you can request

| Control domain                      | Implementation summary                                           | Primary evidence                                                                                                                       |
| ----------------------------------- | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication and session controls | Enterprise auth provider integration and scoped session handling | [Identity and Access](/trust/controls/identity-access)                                                                                 |
| Authorization                       | Tenant and workspace scoped access and role enforcement          | [Identity and Access](/trust/controls/identity-access)                                                                                 |
| Encryption in transit and at rest   | TLS-required communication and encrypted managed storage         | [Encryption and Key Management](/trust/controls/encryption-key-management), [Encryption Standard](/trust/policies/encryption-standard) |
| Secrets management                  | Centralized secret stores with least-privilege access            | [Identity and Access](/trust/controls/identity-access), [Encryption and Key Management](/trust/controls/encryption-key-management)     |
| Monitoring and response             | Centralized logging and security event monitoring                | [Incident Response and Resilience](/trust/controls/incident-response)                                                                  |
| Change control                      | Peer review, CI checks, controlled deployment paths              | [Secure Development](/trust/controls/secure-development)                                                                               |

## Exceptions and governance

Any architecture-control exception requires documented risk, explicit Security and Engineering approval, compensating controls, and a time-bound remediation date.

Evidence requests: [{securityEmail}](mailto:\{securityEmail})