Security & Safety

Last updated: April 11, 2026

1. Our Commitment

At Basecamp ("Company," "we," "us," or "our"), security is not an afterthought — it is foundational to everything we build. Our platform handles sensitive workforce data, financial records, compliance documentation, and automated business processes. We take that responsibility seriously.

This page describes the technical, organizational, and operational security measures we implement to protect your data. We maintain these controls continuously and evolve them as threats change.

2. Infrastructure Security

2.1 Hosting & Network

• Cloud Platform: Our application is hosted on Vercel's enterprise infrastructure, which maintains SOC 2 Type II, ISO 27001, and PCI DSS compliance
• Database: All data is stored in Neon PostgreSQL with SSL/TLS encryption required on every connection (sslmode=require)
• Content Delivery: Static assets are served through Vercel's global edge network with DDoS protection built in
• No Self-Managed Servers: We do not operate physical servers. All infrastructure is managed by SOC 2-certified cloud providers, reducing our attack surface

2.2 Encryption

Data in Transit:

• All connections use TLS 1.2 or higher — enforced via HTTP Strict Transport Security (HSTS) with a one-year max-age, includeSubDomains, and preload directives
• All insecure HTTP requests are automatically upgraded to HTTPS
• WebSocket connections use WSS (WebSocket Secure) exclusively
• Our desktop application enforces HTTPS and rejects any unencrypted connections

Data at Rest:

• Sensitive fields (OAuth tokens, API keys, financial data, personally identifiable information) are encrypted using AES-256-GCM with authenticated encryption
• Each encrypted field uses a unique random initialization vector (IV) and salt, preventing pattern analysis across records
• Encryption keys are derived using scrypt (N=16384, r=8, p=1) — a memory-hard key derivation function resistant to brute-force attacks
• We support key rotation with versioned encryption — old data can be decrypted with previous keys and re-encrypted with the current key without downtime

2.3 Secrets Management

• All secrets (API keys, database credentials, encryption keys) are stored in environment variables, never in source code
• Environment variables are validated at application startup using strict schema validation — the application refuses to start if any required secret is missing or malformed
• Our CI/CD pipeline runs automated secret scanning (Gitleaks) on every commit to prevent accidental credential exposure
• No secrets are ever logged or included in error messages

3. Authentication & Access Control

3.1 User Authentication

• Authentication is managed by Clerk, an enterprise-grade identity provider that supports:
  • Email/password with configurable password policies
  • Single Sign-On (SSO) via Google, Microsoft, and SAML providers
  • Multi-factor authentication (MFA)
  • Session management with configurable timeouts
• All authentication tokens are cryptographically signed and validated on every request

3.2 Organization Isolation

• Every API request validates that the requesting user belongs to the target organization
• Data queries are scoped by organization ID at every level — there is no mechanism by which one organization's data can appear in another's results
• Organization membership changes are managed through Clerk's secure invitation and role management system

3.3 Role-Based Access Control (RBAC)

• Permission Sets allow organization administrators to define granular access rules per team member
• Rules control access at the integration level (which connected services a user can access) and the folder level (which document directories a user can view)
• Permission enforcement operates at two layers:
  • Pre-filtering: Tools and data sources are removed from an agent's available set before processing
  • Execution-time validation: Every tool call re-validates permissions before executing, serving as a hard gate even if filtering fails
• If the permission system encounters an error, it fails closed — all integration tools are removed rather than granting access by default

3.4 Administrative Access

• Platform administration endpoints are protected by a separate authentication system using timing-safe secret comparison to prevent timing attacks
• Administrative actions are rate-limited to the "sensitive" tier (10 requests per 10 seconds)
• Every administrative action is recorded in the audit trail with the administrator's identity, the action taken, and a timestamp

4. Application Security

4.1 Security Headers

Every response from our application includes the following security headers:

Header	Value	Purpose
Strict-Transport-Security	max-age=31536000; includeSubDomains; preload	Forces HTTPS for one year
X-Frame-Options	SAMEORIGIN	Prevents clickjacking
X-Content-Type-Options	nosniff	Prevents MIME-type sniffing
Referrer-Policy	strict-origin-when-cross-origin	Limits referrer information leakage

4.2 Input Validation & Injection Prevention

• SQL Injection: We use Drizzle ORM with parameterized queries exclusively — no raw SQL string concatenation exists in our codebase
• Cross-Site Scripting (XSS): React's default output escaping is active on all rendered content. Email bodies are sanitized using DOMPurify before sending
• Email Header Injection: All email header values (To, Subject, CC) are sanitized to remove carriage return and line feed characters
• Prompt Injection: All organization and agent metadata is sanitized before inclusion in AI system prompts, preventing malicious data from altering agent behavior
• Server-Side Request Forgery (SSRF): Our knowledge ingestion and automation systems block requests to private IP ranges (10.x, 172.16-31.x, 192.168.x), loopback addresses, cloud metadata endpoints (169.254.169.254), and internal TLDs (.internal, .local)

4.3 Rate Limiting

We enforce rate limits across all endpoints to prevent abuse:

Endpoint Type	Limit	Window
Standard API	100 requests	10 seconds
Sensitive (auth, payments)	10 requests	10 seconds
Public endpoints	50 requests	1 minute
AI operations	20 requests	1 minute
Webhooks	200 requests	10 seconds

Rate limiting is backed by Redis with an in-memory fallback, ensuring protection even during infrastructure disruptions.

4.4 Webhook Security

All inbound webhooks from third-party providers are cryptographically verified:

• Stripe: Signature verification using stripe.webhooks.constructEvent()
• Clerk: Svix signature verification with header validation
• Microsoft Graph: Timing-safe clientState comparison with encrypted storage
• JotForm: HMAC-SHA256 signature verification with constant-time comparison

Unsigned or tampered webhook payloads are rejected and logged.

5. AI Agent Security

5.1 Agent Boundaries

Our AI agents operate within strict boundaries to prevent unauthorized actions:

• Outbound Communication Gate: Agents running on autonomous channels (email processing, proactive scheduling) are blocked from sending emails, WhatsApp messages, or invoices without human approval
• Delegation Depth Limit: Agent-to-agent delegation is capped at 3 levels to prevent infinite recursion loops
• Tool Permission Enforcement: Every tool call validates the requesting user's permissions before execution — agents cannot access integrations or data that the user hasn't been granted access to

5.2 Desktop Automation Safety

Our desktop agent (Basecamp Autopilot) includes multiple layers of protection:

Operation Boundaries:

• Blocked websites: Cloud consoles (AWS, Azure, GCP), admin panels, OAuth authorization pages, payment settings, and social media
• Blocked files: System directories, SSH keys, GPG keys, cloud credentials, .env files, and certificate files
• Blocked commands: Destructive operations (rm -rf, sudo), credential theft patterns, supply chain attacks (npm publish), and cloud metadata access

Script Execution Safety:

• Only whitelisted interpreters (Python, Node.js, Bash) are permitted
• Dangerous code patterns are scanned before execution
• Scripts run with a 60-second timeout (5-minute hard cap)
• Working directory is restricted to temporary locations
• First-time script execution requires explicit user consent

Sensitive Application Detection:

• Password managers (1Password, Bitwarden, LastPass, KeePass) are automatically excluded from monitoring
• Banking, healthcare, and system settings applications are blocked by default
• Clipboard content is always redacted from monitoring data
• Window titles are scanned and redacted for passwords, tokens, credit card numbers, and social security numbers

5.3 PII Protection in AI Processing

• Personally identifiable information (PII) access is logged at "high" severity in our audit trail
• Sensitive tool arguments (passwords, tokens, API keys, credentials) are automatically redacted before logging
• Tool execution results are scanned for sensitive patterns (API keys, JWTs, SSNs, credit card numbers) and redacted before audit storage
• The desktop agent sanitizes all traces for PII patterns before transmission to the server

6. Data Protection

6.1 Data Retention

• AI Decision Records: Bulk data fields are truncated after 90 days and records are permanently deleted after 2 years
• Audit Logs: Retained for the full audit period to support compliance requirements
• Desktop Agent Data: Local caches are automatically cleaned after 30 days, with a maximum of 10,000 records per table
• Device Unpairing: All locally cached data is wiped when a device is unpaired from the platform

6.2 Data Minimization

• Desktop activity monitoring captures window switches and application usage — no keystrokes are logged
• Screenshots are compressed, resized (max 1280px wide), and only captured when the screen meaningfully changes
• Sensitive applications are excluded from all monitoring by default
• Privacy mode settings allow organizations to restrict capture to application names only or window titles only

6.3 Data Deletion

• Organizations can request deletion of all their data at any time
• The desktop agent includes a GDPR data deletion endpoint that removes all server-side data for a specific user
• Unpaired devices have all local data automatically erased

7. Third-Party Integration Security

7.1 OAuth Security

• All OAuth flows use HMAC-SHA256 signed state parameters with 15-minute expiration to prevent CSRF attacks
• State parameters include organization ID, user ID, provider name, and timestamp — preventing cross-user and cross-org token theft
• State verification uses timing-safe comparison to prevent timing attacks
• OAuth tokens are encrypted immediately after exchange and stored using our AES-256-GCM field encryption
• Token refresh uses distributed locking (Redis) to prevent concurrent refresh race conditions
• Granted scopes are validated against requested scopes at callback, with discrepancies logged for review

7.2 Connected Services

When you connect third-party services (Google Workspace, Microsoft 365, QuickBooks, etc.):

• Access tokens and refresh tokens are encrypted at rest using AES-256-GCM
• Token decryption only occurs within the scope of the specific operation, and credentials are garbage-collected immediately after use
• Connection health is monitored — inactive or revoked connections are flagged automatically
• Each integration connection is scoped to a single organization and cannot be shared across tenants

7.3 Payment Processing

• We use Stripe for all payment processing — we never store, process, or have access to raw credit card numbers
• Stripe webhook signatures are verified on every notification
• Payment events are processed idempotently to prevent duplicate charges
• Only Stripe's payment_method identifier is stored, not card details

8. Monitoring, Logging & Incident Response

8.1 Audit Trail

Every significant action in the platform is recorded in an immutable audit trail:

• 23+ action types tracked, including authentication, data access, administrative changes, and payment events
• Each log entry includes: user identity, organization, action type, resource affected, severity level, IP address, user agent, and request ID
• PII access events are automatically elevated to "high" severity
• Audit logs capture before/after values for change tracking

8.2 Error Monitoring

• Application errors are monitored in real-time via Sentry with structured error reporting
• Structured JSON logging (via Pino) enables rapid incident investigation
• Log entries include module context, timestamps, and correlation IDs for request tracing
• Sensitive data is automatically redacted from all log output

8.3 Rate Limit & Abuse Detection

• Rate limit violations are logged and tracked
• Circuit breakers protect against cascading failures from downstream service outages
• Failed authentication attempts are recorded with "medium" severity for security monitoring

9. Secure Development Practices

9.1 Code Quality & Review

• All application code is written in TypeScript with strict mode, catching entire categories of bugs at compile time
• Every change goes through pull request review before merging
• Conventional commit formatting is enforced for change traceability

9.2 Automated Security Pipeline

Our CI/CD pipeline runs the following security checks on every pull request:

Check	Tool	Purpose
Dependency Audit	npm audit	Identifies known vulnerabilities in dependencies
Secret Scanning	Gitleaks	Prevents accidental credential commits
Type Safety	TypeScript --noEmit	Catches type-related bugs before runtime
License Compliance	license-checker	Ensures all dependencies use approved licenses
Software Bill of Materials	CycloneDX	Generates SBOM for supply chain transparency
Dependency Updates	Dependabot	Weekly automated security patches

9.3 Dependency Management

• Dependabot checks for dependency updates weekly for both npm packages and GitHub Actions
• Security updates are automatically labeled and grouped to reduce PR noise
• A complete Software Bill of Materials (SBOM) is generated in CycloneDX format and retained for 365 days

10. Desktop Application Security

10.1 Electron Security Hardening

Our desktop application (Basecamp Autopilot) follows Electron security best practices:

• Context Isolation: Enabled — the renderer process cannot access Node.js APIs directly
• Node Integration: Disabled — prevents require() in the renderer
• Sandbox Mode: Enabled — restricts renderer process capabilities
• Navigation Restrictions: The renderer is blocked from navigating to external URLs
• Window Open Handler: New windows are denied; external links open in the system browser

10.2 Credential Storage

• API keys are encrypted using the operating system's native secure storage:
  • macOS: Keychain
  • Windows: Credential Manager (DPAPI)
  • Linux: libsecret
• The application refuses to store credentials if secure storage is unavailable — it will not fall back to plaintext storage

10.3 Automatic Updates

• Updates are distributed via GitHub Releases with platform-specific code signing:
  • macOS: Apple Developer certificate with notarization
  • Windows: Authenticode code signing
• Downgrade attacks are prevented — the updater rejects versions older than the currently installed version
• Updates download automatically in the background and install on the next natural app restart — they never force-interrupt user work

10.4 File System Protection

• Path traversal blocked: .. sequences and symlink escapes are rejected
• System directories blocked: /etc, /System, /Library, /usr, /bin, C:\Windows, C:\Program Files
• Sensitive user directories blocked: .ssh, .gnupg, .aws, .azure, .config/gcloud
• File size limit: 100MB maximum per operation
• Files must be within the user's home directory or /tmp

11. Network Security

11.1 API Communication

• All API communication between the desktop agent and server uses HTTPS exclusively
• A circuit breaker pattern protects against server outages — after 5 consecutive failures, requests are paused for 30 seconds to prevent cascading failures
• Request timeouts are enforced (30 seconds default, 60 seconds for AI operations, 120 seconds for file transfers)
• Exponential backoff with jitter is applied to retries to prevent thundering herd problems

11.2 Webhook Delivery

• All webhook secrets are encrypted at rest
• Webhook verification uses constant-time comparison to prevent timing-based attacks
• Unverified webhooks are rejected with detailed security logging

12. Compliance & Certifications

12.1 Current Measures

We implement controls aligned with the SOC 2 Trust Service Criteria:

• Security: Encryption, access controls, vulnerability management, and incident response
• Availability: Redundant infrastructure, circuit breakers, and offline-first desktop agent design
• Processing Integrity: Input validation, idempotent processing, and audit trails
• Confidentiality: Encryption at rest and in transit, role-based access, and data retention policies
• Privacy: Data minimization, consent management, PII detection, and deletion capabilities

12.2 Regulatory Compliance

• GDPR: Right to access, right to erasure, and data portability supported
• PIPEDA: Canadian privacy requirements addressed through consent management and data handling practices
• PCI DSS: Payment card data is never stored or processed by our application — Stripe handles all card operations

13. Responsible Disclosure

If you discover a security vulnerability in our platform, we encourage responsible disclosure. Please contact us at security@gobasecamp.ai with details of the vulnerability. We commit to:

• Acknowledging receipt within 24 hours
• Providing an initial assessment within 72 hours
• Keeping you informed of remediation progress
• Not pursuing legal action against good-faith security researchers

14. Contact Us

For security questions, concerns, or to report an incident:

• Email: security@gobasecamp.ai
• Website: gobasecamp.ai

For privacy-related inquiries, please see our Privacy Policy.

For terms of use, please see our Terms of Service.