Let's talk about trust.
You're considering a threat intelligence platform that will aggregate your security feeds, store your tech stack profile, and potentially integrate with services like VirusTotal, AbuseIPDB, and Shodan.
That requires trust. And you probably want to know exactly what happens to your data before you sign up.
Fair. Here's the full picture.
The 30-Second Version
If you're short on time:
- AES-256-GCM encryption - Industry standard encryption for sensitive data at rest
- Never stored in plaintext - API keys and credentials are always encrypted
- Encryption keys stored separately - A database breach alone can't expose your credentials
- Two-factor authentication - TOTP apps or backup codes protect your account
- Session management - Configurable expiry, single-device enforcement, manual logout
If you want the details (or your security team is asking), keep reading.
What Gets Protected
Account Data
| Data Type | Protection |
|---|---|
| Password | Hashed with bcrypt (not reversible) |
| Stored for authentication | |
| Session tokens | Encrypted, auto-expire |
| 2FA secrets | Encrypted at rest |
Configuration Data
| Data Type | Protection |
|---|---|
| OpenAI API key | AES-256-GCM encrypted |
| Integration credentials | AES-256-GCM encrypted |
| Tech stack profile | Standard database storage |
Threat Data
| Data Type | Retention |
|---|---|
| Aggregated articles | Indefinite (public data) |
| AI analysis results | Indefinite (derived data) |
| Saved notes | User-controlled |
| Monitor configurations | User-controlled |
Encryption Architecture
We use AES-256-GCM for all sensitive credential storage.
How It Works
When you save an API key (like your OpenAI key for AI features):
Your API Key → Encryption → Encrypted blob → Database
What's actually stored:
v1:a3f2b1c4d5e6f7a8:9b8c7d6e5f4a3b2c:x9y8z7w6v5u4t3s2r1q0...
Version, initialization vector, authentication tag, encrypted data. Without the encryption key, it's meaningless bytes.
Key Separation
The encryption key lives in an environment variable, completely separate from the database.
| Attack Scenario | What They Get |
|---|---|
| Database breach | Encrypted blobs only |
| Application compromise | Additional protections apply |
| Both required | Defense in depth |
No single breach exposes everything.
Tamper Detection
AES-256-GCM is authenticated encryption. If anyone modifies even a single bit of the encrypted data, decryption fails completely.
We don't just encrypt your data. We verify it hasn't been touched.
Account Security
Your data is only as safe as your account. Here's how we protect that:
Password Requirements
- Minimum 12 characters
- Uppercase, lowercase, numbers, special characters
- Common passwords blocked
- Bcrypt hashing (irreversible)
Two-Factor Authentication
- TOTP apps (Google Authenticator, Authy, 1Password)
- Backup codes for recovery
- Required for sensitive operations
Brute Force Protection
- 5 failed attempts triggers 30-minute lockout
- Email notification on lockout
- Rate limiting on all auth endpoints
Session Management
- Configurable session duration
- Single-session enforcement available
- Force logout from all devices
- Automatic expiry
What We Don't Do
Let's be explicit:
We don't log credentials. Not in application logs, not in error reports, not in analytics. If something fails, we log "decryption failed" - not the credential itself.
We don't store plaintext "temporarily." Encryption happens immediately or not at all.
We don't share your data. No analytics providers get your threat intelligence data. No third parties. No exceptions.
We don't sell your data. Your tech stack profile, your feeds, your analysis - it's yours. Period.
Infrastructure Security
Hosting
- Deployed on Vercel (SOC 2 Type II compliant)
- Database on Neon (serverless Postgres)
- All traffic encrypted in transit (TLS 1.3)
Access Controls
- Role-based access (Owner, Admin, Member)
- Principle of least privilege
- Audit logging for sensitive operations
Monitoring
- Real-time error tracking
- Anomaly detection
- Incident response procedures
Team Permissions
For team accounts, access is controlled by role:
| Role | Capabilities |
|---|---|
| Owner | Full access, billing, delete team |
| Admin | Manage members, configure integrations |
| Member | Use features, cannot access admin settings |
Members can use AI features but never see the API keys. Admins can configure integrations but can't transfer ownership. Owners have full control.
Data Retention
| Data Type | Retention Period |
|---|---|
| Aggregated threats | Indefinite |
| AI analysis | Indefinite |
| User sessions | Configurable (max 30 days) |
| Audit logs | 90 days |
| Deleted account data | 30 days then purged |
You can export your data at any time. You can delete your account and all associated data.
Compliance
We implement security controls aligned with:
- SOC 2 - Security, availability, confidentiality
- GDPR - Data protection and privacy rights
- CCPA - California consumer privacy
While we don't yet have formal certifications, our practices follow these frameworks.
The Bottom Line
When you use {P}eelSec:
- Your credentials are encrypted with AES-256-GCM
- Encryption keys are stored separately from data
- Two-factor authentication protects your account
- We never log, share, or sell your data
- You control your data retention
We're asking for your trust. We take that seriously.
Questions?
If your security team needs more details, or you have specific compliance questions, reach out.
We think about security every time we ship code. Because we know what's at stake.
Enjoyed this post?
Subscribe to get new posts and product updates delivered to your inbox.