Security & Compliance

Computer Agents is built with security as a foundational principle. This document outlines our security architecture, data protection measures, and compliance practices.

Security Architecture

Our security model is built on multiple layers of protection:

┌─────────────────────────────────────────────────────────────┐
│                    Edge Security                             │
│  • DDoS protection  • WAF  • Rate limiting                  │
├─────────────────────────────────────────────────────────────┤
│                  Transport Security                          │
│  • TLS 1.3  • Certificate management  • HSTS               │
├─────────────────────────────────────────────────────────────┤
│                 Authentication Layer                         │
│  • API key validation  • User identity  • Scope checking    │
├─────────────────────────────────────────────────────────────┤
│                 Authorization Layer                          │
│  • Resource ownership  • Budget enforcement  • Rate limits  │
├─────────────────────────────────────────────────────────────┤
│                  Execution Isolation                         │
│  • Docker containers  • Resource limits  • Network isolation│
├─────────────────────────────────────────────────────────────┤
│                    Data Security                             │
│  • Encryption at rest  • Access controls  • Audit logging  │
└─────────────────────────────────────────────────────────────┘

Authentication

API Keys

All API access requires a valid API key:

# API key format
tb_prod_[64 hex characters]
 
# Example usage
Authorization: Bearer tb_prod_abc123...

Key Security Measures:

Key Types

Encryption

In Transit

All data in transit is encrypted:

At Rest

All stored data is encrypted:

Secrets Management

Environment secrets (API keys, credentials) receive additional protection:

• Encrypted at the application layer before database storage
• Never logged or included in error messages
• Transmitted only to execution containers via secure channels

Execution Isolation

Container Security

Each task runs in an isolated Docker container:

Container Isolation
├── Separate network namespace
├── Limited system capabilities
├── Read-only root filesystem
├── No privileged access
├── Resource limits (CPU, memory)
└── Automatic cleanup after execution

Resource Limits

Network Isolation

• Containers run in isolated networks
• No inter-container communication
• Internet access configurable per environment
• Egress filtering available

Data Protection

Data Ownership

• User-owned: All data belongs to the authenticated user
• No cross-user access: Strict resource isolation
• Deletion: Users can delete their data at any time

Data Residency

Data Retention

Data Deletion

Users can request deletion of:

• Individual threads and messages
• Environments and associated files
• Complete account deletion

Access Control

User Scope

All API resources are scoped to the authenticated user:

GET /v1/threads      → Returns only YOUR threads
GET /v1/environments → Returns only YOUR environments
GET /v1/agents       → Returns only YOUR agents

Budget Enforcement

Budget controls prevent runaway spending:

Rate Limiting

Audit Logging

What We Log

Log Security

• Logs are immutable once written
• Access restricted to authorized personnel
• Retained according to compliance requirements
• Available for security investigations

Incident Response

Detection

• Automated anomaly detection
• Real-time alerting on security events
• 24/7 monitoring

Response Process

1. Detection - Automated or manual identification
2. Triage - Severity assessment
3. Containment - Limit impact
4. Investigation - Root cause analysis
5. Remediation - Fix and prevent recurrence
6. Communication - User notification if required

Notification

Users will be notified within 72 hours of any breach affecting their data, including:

• Nature of the breach
• Data potentially affected
• Remediation steps taken
• Recommended user actions

Compliance

Infrastructure Compliance

Our Google Cloud infrastructure maintains:

• SOC 2 Type II - Security, availability, confidentiality
• ISO 27001 - Information security management
• ISO 27017 - Cloud security
• ISO 27018 - Cloud privacy

Data Processing

• Data processed in accordance with our Privacy Policy
• No sale of user data
• Third-party processors vetted for security

Security Best Practices

For Users

1. Protect API keys - Never expose in client-side code
2. Use environment variables - Store keys securely
3. Rotate keys - Periodic rotation recommended
4. Monitor usage - Review billing for anomalies
5. Set limits - Configure daily/monthly budgets

API Key Security

// Good: Environment variable
const apiKey = process.env.COMPUTER_AGENTS_API_KEY;
 
// Bad: Hardcoded
const apiKey = 'tb_prod_abc123...'; // Never do this!

Environment Security

// Store secrets in environment secrets, not variables
await client.environments.create({
  name: 'my-project',
  secrets: [
    { key: 'DATABASE_URL', value: 'postgres://...' }
  ],
  // NOT in environmentVariables
});

Reporting Security Issues

If you discover a security vulnerability:

1. Do not disclose publicly
2. Email security@computer-agents.com
3. Include detailed description and reproduction steps
4. Expect acknowledgment within 24 hours

We appreciate responsible disclosure and will credit researchers who report valid issues.

Security Updates

We continuously improve our security posture:

• Regular security assessments
• Dependency updates
• Penetration testing
• Security training for team members

Subscribe to our status page for security advisories.