Skip to main content
Turen is designed with security as a first principle. This page describes the security architecture that protects your organization’s data.

Defense in Depth

Turen provides multiple layers of security:
LayerProtection
TransportAll communication uses TLS 1.2+ encryption
AuthenticationThree distinct key types with minimal privilege
AuthorizationOrganization-level isolation for all data
Encryption at RestSession data encrypted with per-organization keys
Local EnforcementSecurity rules evaluated on-device, not in the cloud

Authentication Model

Turen uses three types of credentials, each with a specific scope:
CredentialPrefixScopeUsage
API Keysk_live_Dashboard APIProgrammatic access for integrations
Registration Keyrk_live_Single registrationOne-time agent onboarding
Agent Secretas_live_Single agentOngoing agent authentication
Key principles:
  • Registration keys are single-use and cannot be reused
  • Agent secrets are unique per machine and can be rotated
  • API keys can be revoked instantly
  • No credential type can access another organization’s data

Local-First Security

Security rules are enforced locally on the developer’s machine, not in the cloud. This means:
  • No round-trip latency — Rules are evaluated in milliseconds
  • Works offline — Once policies are synced, rules work without network access
  • No data leaves the machine unnecessarily — Only telemetry and session data are uploaded

Multi-Tenant Isolation

Every resource in Turen is scoped to an organization:
  • Database queries are filtered by organization_id
  • Session data is stored in per-organization paths
  • Encryption keys are unique per organization
  • API keys and agent secrets are bound to a single organization
There is no mechanism for cross-organization data access.

Agent Identity

Each agent machine has a verified identity:
  • Machine fingerprint — Generated from hardware identifiers (platform-specific)
  • Client ID — Unique identifier derived from the machine fingerprint
  • Clone detection — Turen detects when an agent’s machine fingerprint has been duplicated (e.g., VM cloning) and flags the anomaly

Secret Rotation

Agent secrets can be rotated without re-registration:
  1. Agent requests a new secret via the API
  2. A new as_live_ secret is generated
  3. The old secret is invalidated
  4. The agent stores the new secret locally
This allows regular rotation without disrupting the developer’s workflow.