Hoplite ports local coding agent setups (sessions, memories, MCP servers) to cloud sandboxes. The onboarding flow mirrors your local machine in a multi-tenant environment, then runs hundreds of concurrent agents against production codebases. This lift-and-shift model exposes security boundaries that don’t exist when agents run on localhost.
The core promise is “effortless” deployment. You connect a GitHub repo, Hoplite imports your local config, and agents run in isolated sandboxes. The QA layer records video walkthroughs of every feature before merge. The security question is what happens when local state, credentials, and MCP servers move from a single-user development machine to shared cloud infrastructure.
The Onboarding Attack Surface
Hoplite’s onboarding imports:
- Sessions: Active agent conversations with context windows
- Memories: Persistent facts the agent has learned about your codebase
- MCP servers: Model Context Protocol endpoints that provide tools and data sources
- Local CLI state: Shell history, environment variables, config files
This creates four credential exposure points:
- Environment variables in
.env,.zshrc, or shell profiles that contain API keys, database URLs, and AWS secrets - MCP server authentication tokens that were scoped to localhost but now need cloud endpoints
- Session state that may contain sensitive data from previous conversations (database schemas, internal URLs, PII)
- Memory persistence that could leak cross-project information if isolation fails
The onboarding flow must scrub or vault these before replicating the environment. If it doesn’t, the first agent run in the cloud could expose credentials to logs, video recordings, or other tenants.
Multi-Tenant Sandbox Isolation
Hoplite runs “hundreds of agents concurrently” in isolated sandboxes. The isolation model determines whether an agent can:
- Read another tenant’s codebase or session state
- Write to shared file systems or databases
- Make network calls to internal infrastructure
- Escape the sandbox and access the host
Typical isolation strategies:
| Strategy | Isolation Strength | Performance Overhead | Credential Leakage Risk |
|---|---|---|---|
| Process-level (chroot, namespaces) | Low | Minimal | High (shared kernel, filesystem) |
| Container (Docker, Podman) | Medium | Low | Medium (shared network, volume mounts) |
| VM (Firecracker, gVisor) | High | Medium | Low (hardware virtualization) |
| Serverless (Lambda, Cloud Run) | High | High (cold start) | Low (ephemeral, no shared state) |
Coding agents need filesystem access, network egress, and long-running processes. This rules out serverless. The question is whether Hoplite uses containers with network policies and volume isolation, or micro-VMs with stronger boundaries.
If sandboxes share a Docker network without segmentation, an agent could probe other containers. If they mount a shared volume for codebase access, file permissions become the only barrier.
MCP Server Authentication in the Cloud
MCP servers running on localhost:3000 don’t need authentication. When Hoplite ports them to cloud endpoints, they need:
- TLS termination to prevent credential interception
- Per-tenant API keys to prevent cross-tenant access
- Rate limiting to prevent one agent from exhausting shared resources
- Audit logging to track which agent called which tool
The authentication model likely looks like:
# Local MCP server (no auth)
mcp_client = MCPClient("http://localhost:3000")
# Cloud MCP server (tenant-scoped token)
mcp_client = MCPClient(
"https://mcp.hoplite.sh/tenant-abc123",
headers={"Authorization": f"Bearer {tenant_token}"}
)If Hoplite generates tenant tokens during onboarding, it must rotate them when a user leaves or a project is deleted. If it reuses tokens across sessions, a leaked token grants persistent access.
The MCP server itself becomes a shared service. If it’s multi-tenant, a bug in tenant isolation could expose one customer’s tools to another. If it’s single-tenant (one MCP instance per customer), the deployment cost scales linearly.
QA Video Recordings and Data Retention
Hoplite records video walkthroughs of every feature before merge. This surfaces:
- UI changes (screenshots, DOM snapshots)
- Network traffic (API calls, database queries)
- Console logs (errors, debug output)
- File diffs (code changes, config updates)
If the video includes a database query with PII, or a console log with an API key, that recording becomes a compliance artifact. The retention policy determines how long sensitive data persists in video storage.
Questions for the QA pipeline:
- Are videos stored encrypted at rest?
- Are they scoped to the tenant or globally searchable by Hoplite staff?
- Can a user delete a video after merge, or does it persist for audit?
- Are secrets redacted from console logs before recording starts?
If the QA system runs in the same sandbox as the agent, it has access to the same credentials. If it runs in a separate observability layer, it needs read access to logs and network traffic, which could leak data if misconfigured.
Secrets Management During Onboarding
The onboarding flow must handle secrets that exist in local config files. Three approaches:
- Scrub and prompt: Detect secrets in
.envfiles, remove them, and prompt the user to re-enter them in a vault - Encrypt and store: Encrypt secrets during import and decrypt them at runtime in the sandbox
- Ignore and fail: Don’t import secrets, let the agent fail, and require manual configuration
Option 1 is the safest but creates friction. Option 2 requires a key management system (KMS) and careful access control. Option 3 breaks the “effortless” promise.
If Hoplite uses option 2, the encryption key must be scoped to the tenant. If it’s a global key, a breach exposes all secrets. If it’s per-tenant, key rotation becomes a migration event.
A typical flow:
# Local .env file
DATABASE_URL=postgres://user:pass@localhost:5432/db
STRIPE_SECRET_KEY=sk_live_abc123
# Hoplite onboarding detects secrets
- DATABASE_URL: [REDACTED] (detected: connection string)
- STRIPE_SECRET_KEY: [REDACTED] (detected: API key pattern)
# User re-enters in vault UI
vault.hoplite.sh/tenant-abc123/secrets:
DATABASE_URL: encrypted(postgres://...)
STRIPE_SECRET_KEY: encrypted(sk_live_...)
# Agent runtime decrypts in sandbox
os.environ["DATABASE_URL"] = vault.get("DATABASE_URL")If the vault API is accessible from the sandbox, an agent could enumerate all secrets. If it’s restricted to specific environment variables, the agent can only access what it needs.
Agent Escape and Privilege Escalation
Coding agents execute arbitrary code. If the sandbox allows shell access, an agent could:
- Install packages with known vulnerabilities
- Spawn background processes that persist after the task completes
- Make network calls to exfiltrate data
- Write to shared volumes or databases
Mitigation strategies:
- Read-only filesystem except for a designated workspace directory
- Network egress filtering to allow only approved domains (GitHub, npm, PyPI)
- Process limits to prevent fork bombs or resource exhaustion
- Syscall filtering (seccomp) to block dangerous operations
If Hoplite uses Docker, the default seccomp profile blocks 44 syscalls. If it uses gVisor, the kernel boundary is stronger but performance suffers.
The agent’s execution model determines the risk. If it runs as root inside the container, privilege escalation is trivial. If it runs as a non-root user with capabilities dropped, the attack surface shrinks.
Memory Persistence and Cross-Project Leakage
Hoplite imports “memories” (persistent facts the agent has learned). If memories are stored in a shared database, a query bug could return another tenant’s data.
Example schema:
CREATE TABLE agent_memories (
id UUID PRIMARY KEY,
tenant_id UUID NOT NULL,
project_id UUID NOT NULL,
memory_key TEXT NOT NULL,
memory_value JSONB NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_memories_tenant ON agent_memories(tenant_id, project_id);If the query omits tenant_id, it returns all memories. If it uses project_id alone, it could leak data between projects in the same tenant.
The memory retrieval logic must enforce tenant boundaries:
def get_memories(tenant_id: str, project_id: str) -> list[dict]:
return db.query(
"SELECT * FROM agent_memories WHERE tenant_id = %s AND project_id = %s",
(tenant_id, project_id)
)If the agent can write arbitrary SQL (via a tool or MCP server), it could bypass this filter. The database user must have row-level security (RLS) policies that enforce tenant isolation at the database layer.
Observability and Audit Logging
Hoplite integrates with Linear and Slack to spin up agents from existing tools. This creates audit requirements:
- Which user triggered which agent?
- What code did the agent write?
- What credentials did it access?
- What network calls did it make?
If the audit log is incomplete, a security incident becomes undebuggable. If it’s too verbose, it becomes a performance bottleneck and a compliance risk (logging PII).
A minimal audit event:
{
"event_id": "evt_abc123",
"timestamp": "2026-08-17T00:02:19Z",
"tenant_id": "tenant_abc123",
"user_id": "user_xyz789",
"agent_id": "agent_123",
"action": "code_write",
"resource": "src/index.ts",
"metadata": {
"lines_changed": 42,
"mcp_calls": ["filesystem.write", "git.commit"]
}
}If the audit log is stored in the same database as application data, a breach exposes both. If it’s in a separate append-only store (S3, CloudWatch Logs), it’s harder to tamper with.
Technical Verdict
Use Hoplite when:
- You need to run coding agents at scale without managing infrastructure
- Your team already uses Linear and Slack for issue tracking
- You trust a third party to handle your codebase and credentials in a multi-tenant environment
- The QA video recordings provide enough value to justify the data retention risk
Avoid Hoplite when:
- Your compliance requirements prohibit cloud execution of sensitive code
- You need full control over sandbox isolation and network policies
- Your MCP servers contain proprietary tools that can’t be exposed to a shared service
- You have secrets in local config files that can’t be migrated to a vault
The security model depends on implementation details not visible in the launch post: sandbox technology, secrets management, memory isolation, and audit logging. The lift-and-shift onboarding is convenient but creates credential exposure risk if not carefully scrubbed.