Operationalizing Refine

Refine gives agents a path from intent to software changes. An enterprise deployment must define who can reach that path, what authority it carries, and how its use is recorded.

Assessment baseline: Refine 4.3.2, source commit d7e2baee6a81106554c10afc7e39d49daa3159c6, reviewed 22 September 2026. This is a source-based deployment guide, not a SOC 2 opinion or a test of an enterprise installation. Revalidate against the installed version and effective configuration.

The operating principle

Refine and its child processes are constrained by host permissions and enforced network controls. That is a useful starting point. It does not mean they automatically satisfy every organizational policy or inherit a SOC 2 conclusion. New listeners, external model calls, delegated sessions, and automated actions change how existing authority can be exercised.

Document the controls required for the intended use of Refine, assign an owner to each control, and verify the effective configuration before granting access to enterprise systems or data.

What this review establishes

The source shows a configurable HTTP listener, API/MCP access to shared capabilities, provider CLI execution, Git state synchronization, and host secret backends. The daemon start default is 0.0.0.0:8082. The reviewed HTTP path does not establish authenticated end-user identity before capability dispatch. Bundled Claude and Codex profiles include approval/sandbox bypass flags. These findings require deployment decisions; they do not establish how any particular enterprise host is configured.

Before approval, record the installed commit, actual listen address and firewall exposure, provider arguments, enabled tools, data classification, identity model, and operational owner. See the evidence checklist.

Where to start

Anyone evaluating Refine can begin with how it works and the operating plan. Infrastructure and identity teams can follow the network and authentication pages. Engineering, procurement and legal can use the IP and artifact pages together. Assurance teams can connect the verification workbook to existing SOC 2 controls.

This guide distinguishes current Refine behavior, proposed enterprise controls and deployment evidence still to collect. Source references explain why the controls are needed. No enterprise-specific test results, executed contracts or production configuration are asserted here.