Security
SignalSmith is designed with a security-first architecture. The warehouse-native approach means your customer data stays in infrastructure you control, and SignalSmith’s role is to orchestrate — not store — your data. This section covers how SignalSmith handles data, protects credentials, maintains audit trails, and supports compliance requirements.
Security Principles
Warehouse-Native by Design
SignalSmith’s most important security property is architectural: your customer data lives in your data warehouse, not in SignalSmith. All computation — trait evaluation, audience building, identity resolution — happens as SQL queries executed against your warehouse. SignalSmith stores metadata (model definitions, audience configurations, sync schedules) but not your customer records.
Least Privilege Access
SignalSmith connects to your warehouse with the credentials you provide. We recommend creating a dedicated service account with read-only access to the specific schemas containing customer data. SignalSmith only needs write access to its own operational schemas (CDP_PLANNER, CDP_AUDIT).
Encryption Everywhere
All data in transit is encrypted with TLS 1.2+. Credentials stored in SignalSmith’s metadata database are encrypted at rest with AES-256. API keys are hashed with bcrypt and cannot be retrieved after creation.
Complete Audit Trail
Every user action, API call, sync run, and AI operation is logged with the actor, action, resource, and timestamp. Audit logs are written to both SignalSmith’s internal store and your warehouse’s audit schema, giving you full visibility and the ability to query audit data with SQL.
Security Topics
| Topic | Description |
|---|---|
| Data Handling | How SignalSmith processes, stores, and protects data across the platform |
| Compliance | GDPR, CCPA, SOC 2 compliance support and governance features |
Security Architecture Overview
Key Security Features
| Feature | Description |
|---|---|
| Encryption in transit | TLS 1.2+ for all connections — browser, warehouse, destinations, internal services |
| Credential encryption | AES-256 at rest for all source and destination credentials |
| API key hashing | bcrypt hashing — keys shown only once at creation, support for rotation and expiration |
| Audit logging | Every user action logged with actor, action, resource, timestamp, and source (UI, API, AI) |
| RBAC | Fine-grained role-based access control with 42 permissions across 14 resource categories |
| Data access filters | Row-level access control for team-based data isolation |
| Destination filters | Governance policies controlling which data flows to which destinations |
| AI guardrails | Safety boundaries for AI-initiated operations with approval workflows |
Quick Security Facts
| Question | Answer |
|---|---|
| Where does customer data live? | In your data warehouse. SignalSmith queries it but doesn’t copy it. |
| What data leaves the warehouse? | Only activation data sent to destinations: audience member identifiers and mapped fields. |
| How are credentials stored? | Encrypted at rest with AES-256. Never logged or included in error messages. |
| How are API keys secured? | Hashed with bcrypt. The full key is shown only once at creation. Support for rotation. |
| What’s logged? | Every user action, API call, sync run, and AI operation with actor, action, resource, and timestamp. |
| What encryption is used in transit? | TLS 1.2+ for all connections. |
| Is SOC 2 supported? | Yes. SignalSmith provides audit trails, access controls, and monitoring capabilities that support SOC 2 Type II compliance. |
| Is GDPR supported? | Yes. Warehouse-native architecture, data minimization, right to deletion, and consent management support GDPR requirements. |
Related Resources
- Data Handling — Detailed data processing and protection practices
- Compliance — Regulatory compliance support
- Govern — RBAC, destination filters, and access filters
- AI Guardrails — Safety controls for AI operations