# Who can run code on your device

Source: https://codeherder.com/docs/device-trust/

What a compromised server or a workspace admin can run on a linked device, what is recorded, and how to limit it.

A device runs the work that its server sends. This page says who can make a device run code, what CodeHerder records, and how you limit the risk.

## What the server can do on a linked device

The device dials out to the server. The server then sends spawn instructions: the command, the arguments and the environment of an agent. The device checks each instruction against a copy of the agent settings. The same server filled that copy. So the check does not stop a server that an attacker controls.

Assume this rule: a compromised server can run code on every device that is linked to it. It can do this with the harness approval prompts bypassed. The code runs as the OS user that started `ch device-server`.

CodeHerder accepts this risk for the first release. A device-side allowlist or signing key is not part of it.

## What a workspace admin can do

A workspace admin can run code on a device that a member owns, if the device is linked to the admin’s workspace. An admin has three ways to do this:

- Edit an agent’s launch configuration: the command, the arguments and the environment.
- File or move work that an agent runs. The work runs on any device that is linked to the workspace.
- Attach to a member’s session, or send text to it. The admin then types into a running agent.

Approval prompts are bypassed in all three cases. The device owner does not see a prompt.

## What is recorded

CodeHerder writes these events to the activity feed. Each event names the person or member that acted.

- `session.attached` and `session.detached`, with the attach grant.
- The literal text of every input sent to a session.
- `agent.config_updated`, which says if the command, the arguments or the environment keys changed.
- `device.workspace_linked` and `device.workspace_unlinked`.
- `device.enabled`, `device.disabled` and `device.archived`.

The keystrokes that a person types during an attach are not recorded. This protects secrets and personal data. The attach event also does not say if the person typed anything. Use the input text and the session transcript to see what an agent did.

## How to limit it

Each control below has an owner. Not every device owner holds every control.

- **Unlink, pause or archive a device.** A workspace admin does this. A device owner who is a plain member cannot. An admin can also enable a paused device again.
- **Stop the device server.** Anyone who runs `ch device-server` can stop it. The device then runs no work.
- **Remove the device token.** Delete the token file on the device to cut its link to the server. Register the device again later. See [Device tokens](https://codeherder.com/docs/device-tokens/).
- **Limit what an agent reaches.** Run agents under a dedicated OS user or in a container. See [Isolating agent runs on a device](https://codeherder.com/docs/agent-isolation/).
- **Keep one workspace on each device.** A device that serves one workspace exposes only that workspace’s admins. See [what a shared device shares](https://codeherder.com/docs/self-host-device-isolation/#what-a-shared-device-shares).

## Related guides

- [Isolating agent runs on a device](https://codeherder.com/docs/agent-isolation/) — what an agent can reach, and how to tighten it
- [Device tokens](https://codeherder.com/docs/device-tokens/) — rotate or remove a device token
- [Managing your devices](https://codeherder.com/docs/devices/) — link, pause and retire a device
- [Self-hosted deployment](https://codeherder.com/docs/self-hosting/) — run your own CodeHerder server