Skip to main content
Last reviewed: March 5, 2026 Owner: Security + Engineering Review cadence: Quarterly Status: Implemented This page explains how requests move through Tero, where trust boundaries exist, and which controls enforce those boundaries.

What this page answers

  • Where authentication, authorization, encryption, and logging controls are enforced
  • How traffic is terminated and whether inbound connectivity is required
  • Which architecture layers are Tero-owned vs customer-owned in self-hosted deployments

Current state (as of March 5, 2026)

Tero operates as a control plane. Customer users and systems call Tero APIs over HTTPS, operations are executed within tenant and workspace scope, and security-relevant activity is logged for audit and response.

System flow diagram (hosted default)

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. Requests are authorized to tenant and workspace scope.
  4. Services execute control-plane workflows and metadata processing.
  5. Required data is stored in encrypted managed services.
  6. Security and operational events are recorded for detection and audit.

Trust boundaries and enforcement points

BoundaryWhat it separatesKey controls
IdentityAuthenticated users and integrations vs unauthenticated requestsAuth provider integration, token and session validation, scoped access
NetworkInternet edge vs application ingressTLS-required connections, edge protections, controlled endpoint exposure
ApplicationTenant and workspace operationsTenant-scoped authorization and role-based access patterns
DataControl-plane metadata vs customer source telemetry systemsData minimization model and bounded storage scope
SecretsRuntime services vs credential materialManaged secret stores with least-privilege access

Tenant isolation model (hosted)

LayerIsolation approach
ApplicationRequests are authorized in tenant and workspace scope; role and operation checks are enforced before execution
DataTenant and workspace context is enforced in control-plane data access paths; bounded data model reduces cross-tenant exposure risk
NetworkManaged ingress and service boundaries isolate Internet edge, application ingress, and internal service communication paths

Isolation boundary diagram

Architecture diagrams and review artifacts

We maintain architecture documentation that describes trust boundaries, tenant isolation, and data-flow separation. Public overview material is available in this Trust Center; deeper architecture walkthrough material is available for security review under NDA.

Traffic and termination model

PathTero-hostedSelf-hosted
External API trafficHTTPS to Tero-managed endpointsCustomer-defined ingress path
TLS terminationHosted edge reverse-proxy layerCustomer-defined termination model
Service-to-service trafficManaged cloud networking controlsCustomer networking controls
Inbound connectivity into customer environmentNot required for baseline API integrationCustomer-controlled

Hosted vs self-hosted ownership

AreaTero-hostedSelf-hosted
Infrastructure runtime ownershipTeroCustomer
Environment hardeningTero platform controlsCustomer environment controls
Secrets backend operationsTero-managed implementationCustomer-managed implementation
Private connectivity modelTero-managed hosted modelCustomer-defined
Incident ownership for infrastructure eventsTeroCustomer

Evidence you can request

Control domainImplementation summaryPrimary evidence
Authentication and session controlsEnterprise auth provider integration and scoped session handlingIdentity and Access
AuthorizationTenant and workspace scoped access and role enforcementIdentity and Access
Encryption in transit and at restTLS-required communication and encrypted managed storageEncryption and Key Management, Encryption Standard
Secrets managementCentralized secret stores with least-privilege accessIdentity and Access, Encryption and Key Management
Monitoring and responseCentralized logging and security event monitoringIncident Response and Resilience
Change controlPeer review, CI checks, controlled deployment pathsSecure 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: