Infrastructure
These controls apply across Managed Cloud, BYOC, and on-prem deployments. See Security & Data for the guarantees they provide to your applications and agent workloads.
Architecture
Introspection is Kubernetes-native and deployed by GitOps: every environment is declared in git and continuously reconciled onto the cluster with Argo CD and Helm, so what runs always matches what’s in version control. Managed Cloud, BYOC, and on-prem place the same platform stack in different operating boundaries.
The platform is built on a small, well-understood set of components:
| Component | What it does |
|---|---|
| PostgreSQL | Primary store for configuration and control-plane data |
| ClickHouse | Columnar store for conversations, events, and analytics at scale |
| Valkey | In-memory cache and realtime fan-out |
| Restate | Durable execution for long-running, reliable workflows |
| Envoy Gateway | The edge that authenticates and routes API traffic |
| Zitadel | OIDC identity provider for dashboard access and Introspection-hosted or brokered member login |
Service-account applications authenticate with their own client credentials. Directly federated applications verify end-user tokens against the customer identity provider’s configured issuer and signing keys.
Encryption
In transit
External traffic between clients, SDKs, and Introspection is protected with TLS. Managed Cloud ingress accepts TLS 1.2 or higher. Internal services, databases, and caches remain on private cluster or cloud networks. Transport protection inside that boundary depends on the service and deployment configuration; some in-cluster connections use private HTTP rather than TLS.
At rest
All stored data is encrypted at rest: databases (PostgreSQL, ClickHouse), caches (Valkey), object storage (S3 / GCS / Azure Blob), and Kubernetes secrets and volumes.
Managed Cloud uses provider-managed keys. BYOC and on-prem deployments can use customer-managed keys (CMEK) through the target environment’s key-management service. See Data Handling.
Field-level encryption
Decryptable secrets such as credentials and OAuth tokens use application-level encryption scoped to the owning organization and record. API keys are handled differently: the full key is shown once, then only a one-way hash is stored.
Networking
- Private managed services. Introspection-managed databases, caches, and internal services use private networking. Customer-supplied dependencies follow the networking configured for that deployment.
- Egress control. Sandboxed workloads use domain whitelisting and egress restrictions.
- Consistent posture across clouds. Deployments follow the same security posture wherever they run.
Identity and access
Services authenticate using cloud-native workload identity, with no exported service account keys (IRSA on AWS, Workload Identity Federation on GCP, Managed Identity on Azure).
All access follows least-privilege principles: no broad roles are used, and each workload gets scoped permissions for only the resources it needs.
The dashboard authenticates through OIDC. Server-side SDK callers use environment-scoped runtime API keys or service-account tokens; the CLI uses a member-bound browser login with server-controlled scopes. See the Security model for the full design.
Workload hardening
Application and sandbox workloads run with hardened security contexts, including non-root execution, restricted privilege, and CPU and memory limits. Cluster-level installers and other infrastructure components may require controlled host access to provide the sandbox runtime.
Sandbox isolation
Agent workloads run in ephemeral environments with scoped access to only the resources they need, egress domain whitelisting, and automatic cleanup after a task ends. Follow-up runs inside one interactive task can reuse its sandbox; separate tasks never share sandbox state.
API key handling
API keys are hashed before storage. The full key is shown only once, on creation, and is never transmitted between services in the clear.