Security & audit

Codencer's trust model is conservative on purpose. The bridge has authority over the operator's code through a narrow, allowlisted, audited surface. The relay is transport and audit, not a planner. The connector exposes only an allowlisted proxy to the local daemon. No raw remote shell, no arbitrary filesystem surface, no inference run on data the operator hasn't seen.

Security principles

The principles ship as architectural commitments, not aspirations:

• Bridge, not brain. Codencer executes, waits, records, reports. It does not plan. It does not run inference.
• Local execution. Adapters and artifacts stay local to the daemon side. The executor's process never sees code from another machine.
• Explicit sharing. Connector discovery does not imply exposure. The config file is the allowlist.
• Narrow remote surface. The relay HTTP API and relay MCP expose only instance-scoped orchestration operations. The connector's outbound websocket carries only those operations.
• Evidence first. Results, validations, and artifacts are recorded as local truth. Nothing the planner says is taken as ground truth without a recorded artifact.

What the relay can do

The relay accepts orchestration operations from authenticated planners:

• Open a run against a configured workspace
• Dispatch a step to a specific executor
• Query run status, step status, attempt status
• Retrieve artifacts (over allowlisted paths, bounded transport)
• Subscribe to run events for streaming planner UIs

That's the whole surface. There is no "execute arbitrary command" verb. There is no "read arbitrary file" verb. There is no "open a network tunnel" verb.

What the relay cannot do

Codencer at v0.2.0-beta does not expose:

• Raw shell execution through relay or MCP
• Arbitrary filesystem browsing through relay or MCP
• Generic network tunneling through the connector
• Implicit repo sharing (every workspace must be explicitly configured)
• Unauthenticated remote control

If something claims to do any of these and calls itself Codencer, it is a fork or a misconfiguration.

NOTE — friction: Relay artifact transport is bounded by design. The connector is not a bulk file tunnel. Use the normal artifact list and artifact content APIs for bounded evidence retrieval. Keep large-binary transfer expectations out of the relay path.

What the connector can and cannot do

The connector opens a single authenticated outbound websocket from the operator's network to the relay. Through that socket, the relay can invoke the narrow allowlisted operations on the local daemon. The connector cannot:

• Open inbound ports on the operator's network
• Tunnel arbitrary TCP/UDP traffic
• Read files outside the configured workspaces
• Bypass the daemon's local API

The repo's docs/CONNECTOR.md documents the exact allowlist.

Local safety

Inside the operator's machine, the daemon enforces:

• Repo root anchoring. Execution is bound to an explicit repo root. Adapters cannot escape it.
• Worktree isolation. Each attempt runs in its own git worktree. Parallel attempts cannot collide.
• Persisted state. Run, step, gate, and artifact truth lives in SQLite. Nothing exists only in memory.
• Honest abort semantics. Codencer reports a successful abort only when the active step actually reaches cancelled.

What gets recorded

Every run produces a structured audit trail:

• Every state transition (run opened, step dispatched, attempt started, attempt completed, gate evaluated)
• Every artifact (diff, test output, log) with content-addressed paths
• Every validation (command, exit code, stdout/stderr)
• Every gate (rule, evaluation, pass/fail)
• The actor that initiated each run (planner identity from the auth token)

Append-only. SQLite-backed. Queryable today via the daemon's local /api/v1 and via SQL against the SQLite file.

Authentication

At v0.2.0-beta:

• Planner tokens. The planner authenticates to the relay with a long-lived bearer token. Scopes constrain what the token can do.
• Enrollment tokens. The connector enrolls with the relay using a short-lived token at first connection. After enrollment, the connector authenticates with a per-instance signed challenge/response.
• Local API. The daemon's local API binds to localhost only. Local processes that share the user account can talk to it. This is intentional — the daemon is the local operator's tool, not a network service.

NOTE — friction: Bearer-token mode is the proven execution credential. OAuth protected-resource metadata/challenge support exists for product-facing MCP, but Codencer is not an OAuth authorization server and is not enterprise IAM. For ChatGPT/Claude product OAuth flows, front Codencer with an operator-owned issuer or gateway that issues or translates to a bearer token Codencer accepts. See docs/mcp/OAUTH_FRONT_DOOR.md.

What's NOT in scope at v0.2.0-beta

The roadmap is concrete on what's deferred. From the canonical docs/KNOWN_LIMITATIONS.md:

• SSO and SCIM are not in the v0.2.0-beta scope. Use the OAuth front-door pattern with bearer tokens for now.
• RBAC beyond simple scopes is not in the v0.2.0-beta scope. Today, the planner token's scopes constrain what operations it can perform; richer role-based controls are roadmap.
• A direct public action-log listing API is not in the v0.2.0-beta scope. Use the existing cloud audit and event surfaces for operator visibility until the listing route exists.
• Generic MCP client universal compatibility is not claimed. The proven paths are: relay/cloud HTTP, relay/cloud MCP, official Go SDK smoke helper, packaged operator paths for ChatGPT custom MCP, Claude Code remote MCP, and Anthropic Messages API. See docs/mcp/integrations.md.
• SLA and private deploy are roadmap items.

If your pilot needs one of the deferred features today, we say so. We don't pretend the roadmap is shipped.

Vulnerability disclosure

Security issues should be reported via GitHub Security Advisories on the repo. For high-severity issues that require coordinated disclosure, email founders@codencer.dev directly.

For the deeper operational security reference, see docs/07_security_ops.md in the repo. It tracks current implementation status against the principles above.