Data Classification

CRAFT classifies all data processed by the platform into defined sensitivity levels with corresponding handling requirements. This page covers the classification taxonomy, encryption standards, and data handling policies.

Classification Levels

Public
Internal
Confidential
Restricted

Level 0 — PublicData intended for public consumption. No access control required.

Attribute	Value
Access	No authentication required
Encryption at rest	Inherits from platform default (cloud-managed AES-256)
Encryption in transit	Recommended (TLS)
Retention	Per content policy

Examples: Public Agent Cards, public documentation, published API specifications, marketplace listing descriptions.

Level 1 — InternalData intended for internal use within an organization. Accessible to all authenticated members.

Attribute	Value
Access	Authenticated users with `can_read` permission
Encryption at rest	Required
Encryption in transit	Required (TLS 1.2 minimum)
Retention	Per organization policy

Examples: Agent metadata, project configurations, workflow definitions, health check results, non-sensitive audit log entries.

Level 2 — ConfidentialSensitive business data requiring restricted access. Disclosure could cause significant business impact.

Attribute	Value
Access	Role-based, minimum `developer` or `operator` role
Encryption at rest	Required (AES-256)
Encryption in transit	Required (TLS 1.2 minimum; TLS 1.3 where supported by service)
Retention	Per data governance policy, with right-to-erasure support

Examples: Customer database contents accessed via data connections, query results, data profiling output, enrichment metadata, analytics insights.

Level 3 — RestrictedHighly sensitive data. Unauthorized disclosure could cause severe business, legal, or regulatory impact.

Attribute	Value
Access	`admin` or `owner` role, with audit logging
Encryption at rest	Required (AES-256, CMEK where available)
Encryption in transit	Required (TLS 1.2 minimum for all traffic). mTLS for internal services requires service mesh deployment (e.g., Istio, Linkerd) — not included by default
Retention	Regulatory minimum, with crypto-shredding for erasure

Examples: Data connection credentials, API secrets, Keycloak realm configurations, HMAC webhook secrets, user PII (email, IP address), audit log actor identities.

Encryption at Rest

All persistent data is encrypted at rest using industry-standard encryption:

Component	Encryption Method	Key Management
PostgreSQL	Cloud-managed encryption (AES-256)	Google-managed or CMEK (Cloud SQL), AWS KMS (RDS), Azure-managed (Flexible Server)
Redis	Cloud-managed encryption where available	Provider-managed keys
Secrets backend	Application-level secrets: Infisical (envelope encryption) or GCP Secret Manager (KMS-managed)	Backend-specific key hierarchy
Object storage	Server-side encryption (AES-256)	Provider-managed or CMEK
Webhook secrets	Envelope encryption	Per-subscription encryption keys
Audit log PII	Per-principal encryption keys	Enables crypto-shredding for RTBF

Customer-Managed Encryption Keys (CMEK)

For organizations with strict key management requirements, the platform supports CMEK on cloud-managed services:

GCP CMEK

Use Cloud KMS keys with Cloud SQL and GCS. Configure via Terraform:

resource "google_sql_database_instance" "main" {
  encryption_key_name = google_kms_crypto_key.database.id
}

AWS CMEK

Use AWS KMS keys with RDS and S3. Configure via Terraform with kms_key_id parameters.

Azure CMEK

Use Azure Key Vault keys with Azure Database for PostgreSQL. Configure via Terraform with customer-managed key references.

Encryption in Transit

All network communication is encrypted using TLS:

Channel	Minimum TLS Version	Notes
External API traffic	TLS 1.3	Mandatory for all client-to-platform communication
Internal service-to-service	TLS 1.2	TLS 1.3 recommended
Database connections	TLS 1.2	`sslmode=require` or higher
Redis connections	TLS 1.2	In-transit encryption enabled
Keycloak to IdP	TLS 1.2	Required for OIDC and SAML flows
Webhook deliveries	TLS 1.2	HTTPS required in production environments

Mutual TLS (mTLS)

For zero-trust Kubernetes deployments, the platform supports mTLS for internal service communication via a service mesh (Istio, Linkerd).

Data Handling by Component

Component	Data Handled	Classification	Special Handling
Governance	Organizations, users, roles	Internal - Restricted	PII in audit logs encrypted per-principal
Assets	Artifacts, data connections, files, models	Internal - Restricted	Credentials stored via platform Secrets API (Infisical or ESO), never in DB
Utils	Data catalog, scheduling, context packs, memories	Internal - Confidential	Memory content encrypted at rest; context pack metadata access-controlled
Data Insights	Query results, SQL, visualizations	Confidential	Customer data accessed read-only via connections
Data Governance	Profiles, metadata, DQ rules	Confidential	Metadata derived from customer data
Keycloak	User identities, sessions	Restricted	Realm isolation, password hashing
OpenFGA	Authorization tuples	Internal	No PII, relationship data only

Data Residency

For organizations with data sovereignty requirements:

Region labels: Each tenant is tagged with a data residency region (EU, US, APAC, custom)
Geo-fenced storage: Database partitioning by region ensures data stays within designated boundaries
Regional endpoints: Optional per-region API routing (e.g., eu.platform.example.com)
Cross-region search: Federated queries can span regions with explicit opt-in; results indicate source region

Data Retention

Data Type	Default Retention	Regulatory Override
Audit logs	1 year	Extended retention where required by specific regulation (e.g., financial record-keeping). Note: HIPAA’s 6-year retention (45 CFR 164.530(j)(2)) applies to policies and documentation, not specifically to audit logs
Operational logs	90 days	—
Session data	30 days after last activity	—
Webhook delivery logs	30 days	—
Data profiling results	Organization-defined (recommend aligning with data connection retention)	Per GDPR RTBF; storage limitation principle requires justification for extended retention
Event bus (Redis Streams)	7 days	—

Next Steps

GDPR Compliance

Learn about GDPR data handling, Right to Be Forgotten, and audit requirements.

Network Security

Review TLS configuration, SSRF protection, and network policies.

SOC 2 Controls

See how data classification maps to SOC 2 Trust Service Criteria.

Backup & Restore

Understand backup encryption and retention for disaster recovery.

​Data Classification

​Classification Levels

​Encryption at Rest

​Customer-Managed Encryption Keys (CMEK)

​Encryption in Transit

​Mutual TLS (mTLS)

​Data Handling by Component

​Data Residency

​Data Retention

​Next Steps