An open-source Claude Cowork alternative that keeps the audit record

What an Enterprise org controls in Cowork today

Claude Cowork is Anthropic's agentic product for knowledge work. It ships on the Pro, Max, Ultra, Team and Enterprise plans. On an Enterprise org, an admin enables Cowork, then creates roles that carry the Cowork entitlement and assigns them to identity-provider groups. Roles are additive, so a person in several groups gets the union of permissions. Spend limits resolve through one org-wide setting, "Member limit from groups" under Spending defaults, which decides whether the higher or the lower group limit applies, and an org-level cap overrides individual seat limits. Connectors use a three-gate model: an admin enables the connector org-wide, the user's role includes it, and each person links their own account, unless the org sets up managed authorization through its identity provider (the administrator guide).

The rest of the control set sits in the admin console. It includes network egress allowlists, mount controls, desktop extension allowlists and a private plugin marketplace, plus usage analytics and OpenTelemetry streams to a SIEM. Anthropic's product page lists admin controls, usage analytics, the Analytics API and OpenTelemetry observability for Enterprise. Identity sits underneath, with SSO and SCIM provisioning. IdP groups have to exist before the roles, because roles reference groups rather than individuals.

The record a security review asks for

Anthropic's administrator guide tells admins to assemble a security review packet before deployment. The same section carries the line a reviewer will look for first: "Audit logs record the events listed in Access audit logs, and Claude Cowork activity isn't among them; use the Compliance API for Cowork session transcripts."

Those are two systems with two different guarantees. Audit logs cover the rest of the Claude estate. Cowork sessions reach a reviewer through the Compliance API, and only for Enterprise organizations. A platform lead will be asked to show what an agent did last quarter. The answer comes back as a transcript pulled from a vendor interface, by a process the buyer builds and runs, in a schema the buyer does not version.

The Compliance API is a real control. The gap is ownership. The record of a Cowork session lives in Anthropic's systems, behind Anthropic's API, for as long as the plan and the retention policy allow. An evidence pack that must answer a question two years from now depends on a vendor relationship outlasting the project.

Where a Cowork session runs

The guide is direct about the runtime: "By default on Enterprise plans, Claude Cowork runs locally on each user's machine, with code execution sandboxed in a kernel-isolated environment. On the web and mobile, Claude Cowork sessions run in Anthropic's cloud." The help center puts the controls beside it: on Team plans cloud sessions are on by default, and on Enterprise an owner turns on "Run Cowork in the cloud" and grants the Cowork in the cloud capability to a group through custom roles (the Team and Enterprise article). Local files, applications and the browser still go through the desktop app on the person's computer (Get started with Claude Cowork).

Either mode leaves the deployment work with the customer. The guide asks for MDM distribution, allowlisted domains, minimum OS versions and proxy rules. It names endpoint and network issues as the most common cause of a rollout that stalls. A technical buyer should read that as a fleet project. Every laptop in scope is a machine the product runs on or reaches into.

Connector scope is a role decision

Connector access runs through three gates. An admin enables the connector org-wide, the person's role has to include it, and each person links their own account, unless the org sets up managed authorization through its identity provider. Custom roles control connectors per group, which is the lever an IT lead wants, and the guide puts it plainly: "Org-wide on/off, then per group through custom roles." Roles that were already in place were set to "Always allow" on every connector, so nothing changes until a role is narrowed, and a role created now starts at "Needs approval", where members confirm each call. A built-in role still sees every connector enabled org-wide, subject to the org's tool policies for that connector.

The same controls, kept in a repo you review

Kortix keeps the governance objects in git. kortix.yaml registers what exists, and one agents/<name>.md file holds each agent's prompt. The grant an agent gets, and its permission, are written in its block in the manifest. Grants are deny-by-default. An omitted grant resolves to none, so a new specialist starts with nothing and someone widens it on purpose. That is the same decision as a Cowork role assignment, taken in a file that appears in a diff.

The agent file carries the other half. Its opening explains where the work happens. The session is "an isolated sandbox ... an ephemeral branch of this repo, your own /workspace". Only what the agent commits and pushes survives. The file is packages/starter/templates/​base/agents/worker.md, the worker agent's prompt, and it sits in the same repository as the rest of the project.

Session work reaches main through a change request. Merge is default-deny for agents. The diff, the approval and the merge commit become the record a reviewer reads months later. It sits in the repository the team already clones, next to the policy that allowed the work. Nothing in that chain needs a support ticket or a console someone else operates.

Identity is table stakes at this size, and Kortix meets it: SAML 2.0 single sign-on and SCIM 2.0. The permission model is the part a reviewer can test: Per-resource permissions for people and agents. Roles, groups, and an audit trail. A security team reads the permission check itself. Open source. Read it, fork it, audit it.

What a trial should prove

Run one real task and ask each system for the same artifact: what the agent read, what it changed, who approved it. Cowork answers with a Compliance API transcript for an Enterprise org. Kortix answers with a session branch and a change request in your repository. The reviewer opens the diff without asking anyone for access. If your auditors will accept the second answer, the choice is already made.