Security & Data Protection
When you connect your codebase to Team6, you need confidence that your code, credentials, and data are protected. This page explains the security measures we take at every level.
Why Cloud Agents Are More Secure
As we describe in Why Team6, individual AI tools make developers faster -- but Team6 makes the entire organization more capable. The security implications are just as fundamental: running agents in Team6's cloud infrastructure is inherently safer than running them on developer machines.
- No code on laptops — agents work in isolated cloud environments, not on developer machines that can be lost, stolen, or compromised
- No local credential exposure — agents never touch your team's SSH keys, cloud credentials, or local environment variables
- Centralized audit trail — every agent action is logged and traceable. No blind spots from agents running across different developer setups
- Automatic cleanup — workspaces are destroyed after task completion. No residual code or data left behind
- Controlled network — agents operate in a restricted network environment with no access to external services
- Consistent security policies — enforced centrally across all agents, not dependent on individual developer configurations
Your Code Stays Under Your Control
- Agents work on feature branches and create pull requests. Nothing reaches your main branch without your explicit approval.
- All work is visible in standard GitHub PRs -- same review process your team already uses.
- You can revoke repository access at any time by disconnecting the repo or rotating your GitHub token.
Dedicated Infrastructure
Every project runs on a dedicated worker machine. Your agents, workspaces, and execution environment are physically separated from other organizations -- no shared compute, no noisy neighbors.
Task-Level Workspace Isolation
Within your dedicated machine, every task runs in a fully isolated workspace using git worktrees:
- First task triggers a full repo clone (becomes the base); subsequent tasks use git worktrees — isolated working directories provisioned in under a second
- Each workspace has its own unique feature branch
- Agents cannot access other tasks' workspaces or any files outside their workspace
- Parallel agents never interfere with each other -- separate directories, separate branches
- Workspaces are automatically cleaned up after task completion via scheduled cron jobs
No shared state between tasks means no risk of cross-contamination or accidental leaks between work items.
Credential Encryption
All sensitive credentials are encrypted at rest using AES-256-GCM with authenticated encryption:
| What | How it's protected |
|---|---|
| GitHub tokens | AES-256-GCM encrypted, decrypted only during Git operations |
| API tokens | AES-256-GCM encrypted at rest |
| Encryption keys | Scrypt key derivation (N=16384), managed separately from the database |
| Per-message security | Unique salt + IV per encryption operation (semantic security) |
| Logs | Credentials are never written to logs or API responses |
Multi-Tenant Data Isolation
Your project data is surrounded by four nested isolation boundaries. Each boundary is independent -- even if an outer layer is compromised, the inner layers still protect your data:
| Boundary | What it isolates |
|---|---|
| Dedicated Machine | Each project gets its own worker machine -- separate compute, memory, and disk from every other organization |
| Per-Project Queue | BullMQ queues namespaced by projectId with isolated Redis keys. Tasks from one project can never enter another project's queue |
| Git Worktree per Task | Every task runs in its own worktree with a unique branch. Agents cannot access other tasks' files or branches |
| PostgreSQL RLS | Row-Level Security policies on 30+ tables. The database engine itself refuses cross-tenant queries -- no application code can bypass this |
Row-Level Security is the critical innermost boundary. Even if every outer layer fails, the PostgreSQL engine will not return another project's data. This is enforced at the database level, not in application code.
Queue & Process Isolation
Each project gets its own dedicated job queue (agents-{projectId}). Tasks from one project can never leak into another project's queue. Workers consume only from their assigned project queue.
- Per-project BullMQ queues with isolated Redis namespaces
- Per-project worker processes — separate filesystem, separate environment variables
- Agent heartbeat monitoring every 30 seconds — stale or crashed agents are detected and recovered automatically
Agent Boundaries
AI agents are strictly scoped:
- Agents can only read and write files in connected repositories
- Agents cannot access your environment variables, CI/CD secrets, API keys, cloud credentials, or any data outside the repo
- Agents cannot make network requests to external services
- All agent actions are recorded in an immutable audit trail via real-time streaming traces
- Agent health is continuously monitored — heartbeat every 30s, stale detection at 90s, automatic crash recovery
Authentication & Access Control
| Mechanism | Details |
|---|---|
| User authentication | GitHub OAuth -- no passwords stored |
| Session management | JWT tokens with server-side revocation via Redis |
| Role-based access | Owner, Admin, Member -- each with scoped permissions |
| Token revocation | Instant invalidation of compromised tokens |
Input Validation & API Security
- All API inputs validated with Zod schemas before processing -- no unvalidated data reaches business logic
- Rate limiting configured to fail closed -- if Redis is unavailable, requests are rejected (not allowed through unprotected)
- Security headers via Helmet: CSP, HSTS, X-Frame-Options, X-Content-Type-Options
- Git command injection prevention -- all Git commands use
spawn()with argument arrays, never shell string interpolation - SSRF prevention -- repository URLs are validated, private IP addresses blocked, only approved domains allowed
Audit Trail
Every action in Team6 is traced:
- Task creation, assignment, and status changes
- Agent execution start, progress, and completion
- Git operations (clone, branch, commit, push, PR creation)
- Data access, exports, and deletions
- Authentication events and permission changes
Traces are immutable and available for review at any time.
Compliance Readiness
Team6 includes built-in capabilities to support compliance requirements:
| Capability | Description |
|---|---|
| Data Subject Access Requests | Export all data associated with a user |
| Right to Erasure | Delete all user data on request |
| Data Portability | Export project data in standard formats |
| Data Retention Policies | Configurable auto-deletion with admin review |
| Consent Management | Granular, versioned consent tracking |
| Audit Logging | Immutable records of all data operations |
Designed to support GDPR, CCPA, SOC 2, and HIPAA compliance requirements.
Summary
| Area | What we do |
|---|---|
| Infrastructure | Dedicated worker machine per project -- no shared compute |
| Code access | Feature branches + PRs only. You approve every merge. |
| Workspaces | Git worktree isolation per task, auto-cleanup |
| Queue isolation | Per-project BullMQ queues, separate worker processes |
| Credentials | AES-256-GCM encryption at rest |
| Tenant isolation | 4-layer protection with database-enforced RLS |
| Agent scope | Repository-only access, no secrets, no external network |
| Authentication | GitHub OAuth + JWT with instant revocation |
| API security | Schema validation, rate limiting (fail-closed), SSRF prevention |
| Audit | Immutable trace of every action |
| Compliance | GDPR, CCPA, SOC 2, HIPAA readiness |