BENCHYARD GUIDES
Security and data boundaries
Benchyard runs code for you and holds your sessions. This page says plainly what is protected and what is not, so you can decide what to trust it with.
Last reviewed . What is available depends on your installation and account.
What do credential keepers protect?
An agent needs your sign-ins and keys to do its work, but it does not need to see them. For a protected credential the workspace gets a stand-in. A credential keeper outside the workspace holds the real value and adds it only to requests for the service that credential belongs to. The agent can use the credential at that service while the workspace runs, without ever having its value.
Protected this way: your subscription sign-in for Claude Code, Codex or Cursor; your own API key for a service Benchyard knows; a secret you tie to a service's address; a team's key, unless the team sends it through a gateway of its own; and the access token you use for GitHub or GitLab.
Not protected: a secret that is not tied to a service's address; a team's key that goes through the team's own gateway; access keys for cloud accounts, private keys and database passwords; and anything saved in a file in the workspace. An agent can read all of these.
Two more limits. Some programs do not send their requests by way of the keeper, and a protected credential does not work in them. And a service that repeats back what it is sent would show the value to whoever asked.
How is what I store protected?
Your agent sign-ins, API keys and secrets are stored encrypted, with a separate key for each person and each team. Passwords are stored in a form that cannot be read back.
Benchyard is not end-to-end encrypted. The service has to use your credentials on your behalf and show you your sessions, so the party that runs it can access them. On the hosted service that is Benchyard; on an installation your company runs, it is your company.
Is every workspace isolated the same way?
No. A container workspace runs in a sandbox of its own, with its own network rules. A machine workspace is a virtual computer of its own that accepts no incoming connections.
Where a workspace gives you administrator rights, an agent working for you has them too, and can change more of the workspace, including the parts of Benchyard that run inside it. Being a team's administrator gives no access to another member's workspace.
What can a workspace reach on the network?
The public internet. It cannot reach addresses inside private networks, and it cannot send email directly. There is no list of allowed destinations, so anything an agent can read could be sent out.
Each workspace has a traffic allowance: a limit on how much it can send, which fills up again over time. Whether running out restricts the workspace is up to the installation's administrators, and it does not unless they turn that on. A restriction stops new connections; ones that are already open carry on.
What can a team administrator access?
A team can share rules, skills, tools and agent sign-ins, and see its usage. Each workspace still belongs to the person who made it: a team's administrator cannot open another member's workspace, or start and stop it.
A shared tool that runs code reaches a member's workspaces only after that member allows it. Shared rules guide agents; they are not an enforced security policy.
How are previews separated from the console?
A preview opens at an address separate from the Benchyard app, with a sign-in of its own, and only for the workspace's owner.
What you see in a preview is still a program running in the workspace. Keeping it at a separate address does not make it trustworthy, and does not make it a link you can share.
How do people sign in, and what is recorded?
You sign in with a username and password or with a passkey. For two-factor authentication you can use a passkey, an authenticator app, approval from a device where you are already signed in, or a recovery code; an installation can require it. Signing in through a company's single sign-on is not available. The devices you are signed in on are listed, and you can sign any of them out.
An installation's administrators have a record of what was done to accounts, sign-ins, teams and settings, and by whom. It does not cover what happens inside workspaces and sessions, and it never holds secret values. They also have a list of problems the installation ran into. Neither has a set period after which entries are removed.
What assurances are offered here?
This page describes how the product behaves. It is not a certification, an uptime agreement or a statement of compliance. Contact us to discuss your requirements before requesting access.