---
title: How we handle your data
slug: how-we-handle-your-data
docTags: 
createdAt: 2025-07-23T01:09:41.331Z
---

## Overview

This document provides a high-level summary of how our scanner handles credentials found in your environment.

## Key Security Principles

How we handle credentials found by your scanner is built on these core principles:

1. **Never Store Raw Credentials** - We only store cryptographic fingerprints and metadata
2. **Volatile Memory Only** - Raw credentials exist only in RAM during processing
3. **Immediate Verification** - Credentials are verified using safe, read-only API calls
4. **Automatic Cleanup** - Go's garbage collector ensures memory is cleaned up
5. **Complete Isolation** - Each customer has isolated instances and databases

## How It Works

The following lays out what happens inside the TruffleHog Enterprise scanner.

### 1. Discovery

When our scanner finds a potential credential, it:

- Identifies the credential type (AWS, GitHub, Azure, etc.)
- Extracts the credential data
- Prepares for verification

### 2. Verification

We immediately verify the credential by:

- Making a safe, read-only API call to the service provider
- Testing if the credential is valid without modifying any resources
- Using appropriate endpoints for each service (e.g., AWS STS, GitHub API)

### 3. Analysis

For many verified credentials, we can perform additional analysis:

- Discover what resources and permissions the credential has access to
- Assess the potential impact and scope of the credential
- Identify the creator of the credential

All using safe API calls for all analysis operations.

### 4. Storage

We store only:

- **Cryptographic fingerprints**
- **Redacted portions** (e.g., "sk\_live\_1234...")
- **Metadata** about where it was found and attributes about the credential

See [Data flow](docId\:loqEjRuNRsXDDRIE5bzGu) for more information on what information is transmitted.

### 5. Cleanup

After processing:

- Raw credentials are no longer referenced
- Go's garbage collector automatically reclaims memory
- There is never persistent storage of raw credentials

## Deployment Models

### On-Premises Scanner

- **Completely local processing** - All scanning happens in your infrastructure
- **Secure cloud environment** with customer isolation, and encryption in transport and in storage
- **Only metadata sent to cloud** - never raw credentials
- **Comprehensive security controls** and audit logging

### Cloud Scanner

- **Isolated processing instances** per customer
- **Secure cloud environment** with customer isolation, and encryption in transport and in storage
- **Only metadata sent to cloud** - never raw credentials
- **Comprehensive security controls** and audit logging

## Security Measures

### Data Protection

- TLS encryption for our API communications
- mTLS encryption for database connections
- Database encryption for stored metadata
- Strict access controls and audit logging
- Year-round SOC 2 Type II auditing and GDPR compliance

### Verification Safety

- Read-only API calls only
- No state-changing operations

### Memory Security

- Secure memory allocation practices
- Process isolation per customer
- Automatic memory cleanup

## What We Don't Do

- ❌ Store raw credentials found in any persistent storage
- ❌ Log raw credentials in any log files
- ❌ Share credential data between customers
- ❌ Make state-changing API calls during verification

## Summary

**Finding leaked credentials is safe with us.** 

Our architecture is designed with security as a primary consideration, ensuring that:

- Only metadata, redacted versions, and cryptographic fingerprints are stored by us
- Verification uses safe, read-only operations
- Memory is automatically cleaned up
- Complete customer isolation is maintained

We understand the sensitivity of credential data and have built multiple layers of protection to ensure your credentials are handled safely and securely.

If you'd like to dive in a bit deeper, see our [Data flow](docId\:loqEjRuNRsXDDRIE5bzGu) documentation.