Security responsibilities

Keeping your work safe is shared. Refactor enforces some things for every organization. Others depend on choices your organization admins make. This page says which is which, and what is on by default.

At a glance#

What Refactor enforces#

Organizations and workspaces are kept apart#

On for every organization.

• Every request is tied to one organization and is refused if the organization cannot be verified.
• Each organization has its own database and its own storage bucket.
• Each workspace runs in its own isolated environment. The agent in one workspace cannot see another workspace's files.
• A person from another organization cannot read or change your organization's allowed sites, network access settings or requests.

Who can reach a workspace#

On for every organization.

• A workspace is private to its owner until it is shared. Access is always given by a person, never assumed.
• Each person's access to an open workspace is checked on every action, against what they were given: view, edit, or run the agent.
• An organization admin can see that a private workspace exists, but must grant themselves access to look inside, and that grant is recorded.
• A personal workspace can be reached by its owner only. Whatever your organization's settings, it reaches only the few services Refactor needs to run it.

Links shared outside your organization#

On for every organization.

• A link that lets someone outside your organization follow an engagement opens only with a 6-digit code emailed to the address the link was made for. The link by itself shows nothing.
• The person opening the link cannot change where the code is sent.
• A code works for 10 minutes and stops after five wrong tries. Only a scrambled form of it is stored.
• A link ends when an admin ends it, and every link for an engagement ends when the engagement is closed. No link can be made for a closed engagement.

See Share progress with someone outside your organization.

Credentials stay out of the workspace#

On for every organization. The agent uses AI models, GitHub, data sources and connected storage without being handed their credentials. See Credentials and the agent.

Restricted network access#

Turned on per organization by Refactor. When it is on:

• A workspace, the agent, the commands it runs and its browser can reach only the few services Refactor needs to run a workspace (listed under Platform in Connections), the sites allowed by the workspace's network access setting, and the sites people have added for it. Everything else is refused.
• Each workspace has one of three settings: Trusted sites (what a workspace starts with), Added sites only, or Any site.
• Only an organization admin can change a setting. Any site is given to one workspace at a time and asks the admin to confirm.
• The agent cannot add a site or change a setting. When it is refused a site, it says so and a person decides.
• Changes to the allowed sites and to settings are written to an audit log, with who made them.

Allow a site explains each of these in the console.

The trusted sites list#

Part of restricted network access. Refactor maintains one list of sites that development work commonly needs, in these groups:

• Code hosts.
• Package sources for JavaScript, Python, Ruby, Rust, Go, Java and other languages.
• Linux package mirrors.
• Public container registries.
• Documentation and command-line tool downloads for the main cloud providers.

The list leaves out sites whose purpose is to accept uploads from anyone, such as paste sites, file sharing and general cloud storage. In a workspace, Connections shows every site in each group and why it is there.

Anthropic's sites are on the list only while your organization has an Anthropic model turned on in Settings, Models. If an admin turns every Anthropic model off, workspaces stop reaching them within a few minutes. The agent's own use of a model does not depend on this.

The agent's browser#

With restricted network access on, the browser in a workspace follows the same rule as everything else in it.

• It opens only sites the workspace is allowed to reach. A refused site is named, with a way to allow it.
• The agent can put the workspace's files into a page only on a site that a person has marked for uploads.
• Each refused site and each upload by the agent is recorded.

Without restricted network access, the browser can open any public site and the agent can upload to any of them.

Organizations that handle health data#

Refactor can mark an organization as handling health data. Refactor sets this, not your admins. With restricted network access on, it forces three things:

• Every workspace is set to Added sites only.
• Any site is never available.
• A site for one workspace can be added only by an organization admin or an owner of that workspace. Other people who can edit the workspace send a request, which an owner or admin allows or declines. Fibo tells the owners and admins that a request is waiting.
• A site can be marked for uploads only by an organization admin or an owner of that workspace.

One more rule applies whether or not restricted network access is on. On a service's email address, an allowed sender written as a whole domain (@example.com) lets everyone at that domain send work in and lets the agent write to them. In an organization that handles health data, only an organization admin can add one, and must confirm each one. Who confirmed it and when are recorded at once. That entry is shown to your admins, in the audit record, only once restricted network access is on for your organization.

One audit record for your organization#

What your organization configures#

With restricted network access on, your organization also configures:

Your organization vouches for each site it adds. An allowed site can receive anything the workspace sends it, so add only sites the work needs, and mark for uploads only the ones that should receive your files.

To have your organization marked as handling health data, or to have restricted network access turned on, contact Refactor.

What neither of us can do#

• See inside an allowed site. Refactor controls which sites a workspace can reach, not what is sent to them. Nothing inspects the content.
• Control what a person types. A person driving the browser can type anything into a site that is allowed.
• Make a code host or package source one-way. These sites accept what an account holder publishes or pushes to them. They are on the trusted sites list because fetching code and installing packages needs them. A workspace set to Added sites only does not reach them unless you add them, with two exceptions. Every workspace reaches the public npm package registry, because Refactor installs the agent from it. And where Refactor is connected to GitHub, a workspace with a repository connected to it reaches GitHub through that connection: it can change only that repository, and it can read public GitHub, so text anyone has published there can reach the agent. A workspace with no repository connected reaches nothing on GitHub. Refactor records each such read of public GitHub it can recognize, for an organization admin to see under Settings, Audit.
• Limit an app to less than the workspace. Anyone who can view a workspace can open the apps in it, and an app can show any file in that workspace. Share a workspace only with people who may see everything in it.
• List every refused attempt. Refused connections in a workspace lists what the workspace's browser was refused. A command in a terminal or a package install that could not reach a site is refused all the same, but is not listed.

Checklist for a new organization's admin#

1. Choose your admins. Keep the number small. Admins set network access, manage people and have full access to services. On Settings, People, set each person's role.
2. Ask Refactor two things before work starts: whether restricted network access is on for your organization, and, if you handle health data, to have your organization marked as doing so.
3. Review who can open each service. On each service's Access tab, check what everyone in the organization gets and who has more.
4. Choose which models may be used. On Settings, Models, turn off any provider or model you do not want used.
5. Set how long finished work is kept for each service that needs a limit, on the service's Configuration.

If restricted network access is on:

1. Choose what every workspace starts with. On Settings, Network, pick Trusted sites or Added sites only.
2. Add the sites all your work needs on Settings, Network, and the sites one service needs on that service's Access tab.
3. Mark for uploads only the sites that should receive your files.
4. Check for workspaces set to Any site. Settings, Network lists every workspace that has its own setting. Put back any that no longer need it.

Then, as part of normal running:

1. When someone leaves, remove them on Settings, People. A workspace they already have open can keep working for up to 30 minutes.
2. Look at Refused connections in a workspace when the agent reports it could not reach a site, and allow only what the work needs.

Related#

• Security and data describes how the product behaves today, including retention.
• Allow a site covers the network access settings step by step.
• People, groups and access covers roles, groups and sharing.