Connectors

An enclave already runs its own source host, issue tracker and wiki. A connector lets the agent read those services, and write to them where the administrator allows, as the signed-in developer.

How a connector runs

Each connector is one static Go binary with no third-party dependencies, built with CGO_ENABLED=0. It speaks MCP over standard input and output. The agent's worker starts it as a local MCP server inside the worker boundary, so a connector never opens a listening socket. The MCP implementation is about a hundred lines in testifysec/connectors/internal/connector/stdio.go instead of the official SDK, which would have added nine third-party modules to a process that holds a user's credential.

What a connector is locked to

These limits are in the shared library on main (testifysec/connectors/internal/) and apply to every connector:

• One service. The HTTP client is bound to one base URL. It refuses any other host, any path outside the base, any redirect that leaves the base, and plain HTTP (except to loopback in tests). It ignores proxy environment variables. Responses are capped at 8 MiB.
• The developer's own credential. The connector reads a short-lived token from a file on every request and sends it as the developer. There is no shared service account. In the design the session broker provisions that file per user.
• Configuration from the administrator only. A connector takes its settings from flags or BADGER_CONNECTOR_* environment variables. In a managed session the model, user settings and repository files have no way to set them, and mcp add, plugin install and the connect routes stay refused.
• Untrusted output. Every result is wrapped in an untrusted-external-content block naming the source and tool and capped at 48 KiB. Any credential the connector itself sent is replaced with [redacted] before the result leaves it.
• Fixed error text. Authentication, permission, not-found, rate-limit and server errors become short fixed messages. Validation errors keep at most 300 bytes of the service's message, with credentials removed.

Read and write tools

Every tool is registered as read or write. Without --enable-writes, write tools are not registered at all: they are absent from tools/list, and calling one by name returns "unknown tool". Read tools carry the MCP annotation readOnlyHint: true, write tools false.

The connectors provide:

GitLab write tools refuse any line starting with /, because GitLab runs it as a quick action, and refuse labels that carry the marking prefix. Push, merge, approve, branch and tag creation, pipeline retry and settings changes are deliberately absent: code reaches a repository through Pushgate, not through a connector.

Classification

Each connector has one classification, the marking the administrator sets for the service it reads, and every result it returns carries that marking. The marking belongs to the connector, not to individual items. See classification markings for the rule and its status.

Admission (designed)

The planned profile entry for a connector names the binary's SHA-256, the base URL, the token and CA file paths, whether writes are on, the service's marking, and per-tool permissions such as "jira_add_comment": "ask". Only the administrator's signed profile will set it. Until it is built, there is no supported way to attach a connector to a managed session.