Security Overview

Architecture: Bring Your Own Agent

Bridge Town is a Bring Your Own Agent (BYOA) platform. You connect your own AI agent — Claude, Codex, Gemini, or any MCP-compatible agent — to Bridge Town’s MCP server via an authenticated Streamable HTTP connection.

Bridge Town does not call large language models on your behalf. Your prompts travel from your AI client to your LLM provider; they never touch Bridge Town’s infrastructure. Bridge Town receives only structured MCP tool calls: typed inputs such as model names, Python code, query strings, and file paths.

This architecture has direct security implications:

Bridge Town never stores or processes your open-ended prompts.
Your agent selection and LLM provider relationship remain under your control.
Every interaction with Bridge Town is a structured, logged tool call — not a freeform conversation.

Authentication

Bridge Town requires authentication on every request. There is no anonymous or guest access.

MCP OAuth 2.1

For interactive use with Claude.ai, Claude Desktop, and Codex, Bridge Town implements the MCP OAuth 2.1 specification:

Dynamic Client Registration — MCP clients register automatically; no manual setup required.
PKCE flow — browser-based login via Auth0; no static credentials required.
Localhost relay — supports Codex and other local MCP clients that cannot receive direct callbacks.

API Tokens

For non-interactive automation (CI, scheduled jobs), Bridge Town supports btk_-prefixed API tokens:

Stored as argon2id hashes; the plaintext is returned only at creation time.
Carry the full permissions of the issuing user — they are not scoped credentials.
Set expires_in to limit validity; revoke immediately when no longer needed.
Prefer OAuth for interactive sessions where possible.

Tenant Isolation

Every project, model, data source, token, and audit log belongs to exactly one tenant. Cross-tenant access is not possible.

PostgreSQL Row-Level Security (RLS) enforces isolation at the database layer. Every request sets a per-session tenant context before executing any query:

SET LOCAL app.current_tenant_id = '<tenant-uuid>';

RLS policies on every table filter rows to the current tenant. This means:

A SQL injection cannot reach another tenant’s data.
Application bugs cannot leak cross-tenant rows.
Even raw database queries are tenant-scoped.

Project storage and sandbox containers are also tenant-scoped. See Tenant Isolation for the full technical details.

Sandbox Execution

Model Python code runs in ephemeral Docker containers with strict isolation:

Constraint	Value
Network	`--network none` — no outbound or inbound connections
Root filesystem	Read-only
Source code	Mounted read-only at `/repo/`
Data	Mounted read-only at `/data/`
Outputs	Writable tmpfs at `/outputs/` and `/tmp/` only
Timeout	5 minutes (hard cap)
Memory	Capped per container

Containers are created per run and destroyed after execution. No state persists between runs. See Sandbox Execution for details.

Encryption

Layer	Method
Data at rest (database)	AWS RDS AES-256 encryption
Data at rest (S3)	Server-side AES-256 encryption
Data in transit	TLS 1.2+ (Caddy terminates TLS with HSTS)
OAuth refresh tokens	AES-256-GCM before storage
API tokens	argon2id hash; plaintext never stored

Audit Logging

Every MCP tool invocation and authentication event is written to AWS CloudWatch. Log entries include tenant ID, user ID, tool name, timestamp, and outcome. The audit_log table in PostgreSQL has an immutability trigger — records cannot be deleted or modified by application code.

Dashboard sharing requires the recipient to sign into Bridge Town. There are no anonymous public share links. Sharing is available on the Pro plan and above.

Cross-tenant model sharing (via the sharing tool module) requires explicit acceptance by the recipient tenant and is recorded in the audit log with full provenance.

Certification Roadmap

Bridge Town is designed with controls aligned to SOC 2 Trust Service Criteria: tenant isolation, access controls, audit logging, encryption, and incident response procedures. Formal SOC 2 Type II certification is on our roadmap and has not yet been achieved.

Do not interpret any language on this site as a claim of SOC 2, GDPR, CCPA, or HIPAA certification. We comply with applicable legal requirements; compliance is an ongoing posture, not a one-time certification event.

Reporting Vulnerabilities

See SECURITY.md for our coordinated disclosure policy, or email security@bridgetown.builders.