For administrators

This page is for people who deploy Cuewire and set its rules for a team. It covers the organisation’s policy, single sign-on, directory sync, deployment, a policy per computer and the audit log.

Figure: Two policies can apply on one computer. Whatever either one forbids stays forbidden.

Your organisation

You run your organisation from the Team sheet: press Ctrl+K (Cmd+K on a Mac) and choose Team…. Starting an organisation, buying seats, inviting people and roles are explained in Teams and organisations. In short:

• Seats come from the Team subscription. Admins buy them with Buy seats…, later Buy more seats…. Members hold seats in the order they joined.
• Invitations go to an email address. They last 14 days and hold a seat while they wait.
• Admins invite and remove members, set the policy, and share roles and arrangements. Only the owner makes admins, removes them, hands ownership on, and sets up directory sync and single sign-on.

The organisation’s policy

Admins set the policy in the Policy section of the Team sheet, with Change policy:

• Skip permission prompts only in a sandbox;
• Forbid typing into another agent’s terminal (raw keystrokes from cuewire ask --raw);
• the Agents allowed;
• the Models allowed and the Remote hosts allowed.

Figure: Changing the organisation’s policy.

The policy applies to every member, with or without a seat. Each member’s app applies it at its next licence refresh, within a day. Joining or leaving applies at once. The policy travels in each member’s signed licence, so members can’t change it.

Single sign-on (OIDC)

Members at your company’s email domain can sign in through your identity provider instead of with emailed codes. Okta, Entra ID and any OpenID Connect provider work. Then the provider’s MFA and access rules apply.

1. Verify your domain. In the Single sign-on section, the owner types the domain (for example example.com) and clicks Claim. Cuewire shows a DNS TXT record: _cuewire-verify.example.com with a value cuewire-verify=…. Add it in your DNS. Click Copy value to copy the value. Then click Check. A domain can belong to one organisation only.
2. Register Cuewire with your provider as a web application that uses the authorization code flow. Use the redirect URI https://api.cuewire.dev/v1/sso/callback. Note the issuer URL, the client ID and the client secret.
3. Turn it on. The owner types the Issuer URL, Client ID and Client secret in the sheet and clicks Turn on single sign-on. Cuewire reads your provider’s discovery document to find its endpoints.

Figure: A claimed domain waits for its TXT record. Click Check once it is published. (This picture was taken with a test service; your redirect URI starts with https://api.cuewire.dev.)

From then on, anyone who signs in to Cuewire with an address at a verified domain goes to your provider in their browser:

• A first page names your provider and the address. When they finish at the provider, the browser hands the sign-in back to the Cuewire app on their own computer.
• Sign-in for those addresses works from the app only, not from a link someone else sent.
• The provider must sign in the same address that was typed.
• The owner keeps signing in with codes. So a provider outage can’t lock the organisation out.

Turn off single sign-on, or removing the domain, brings codes back for those addresses.

Warning

Keep the TXT record published. Cuewire looks for it again every day. A domain whose record is missing three days in a row stops counting as verified.

Directory sync (SCIM)

Connect Okta, Entra ID or any SCIM 2.0 provider. The people it lists are invited, and those it turns off leave.

1. In the Directory sync section, the owner clicks Turn on directory sync. Your organisation needs Team seats first. Only the owner can do this, since the directory can remove admins.
2. Cuewire shows the base URL and a token, once. Click Copy token.
3. In your identity provider, add a SCIM 2.0 app. Use the base URL https://api.cuewire.dev/scim/v2 and the token as a bearer token (Okta: “HTTP Header”; Entra: “Secret Token”). Turn on creating, updating and deactivating users. Group push isn’t used: assign people to the app.
4. Assigned people see an invitation from your directory when they sign in to Cuewire with their work address. It reads, for example, Acme’s directory lists you: join as a member. It doesn’t expire, and holds no seat until they join.

The section then shows, for example, On: 12 listed, 10 active, 2 not joined yet.

When the provider deactivates or deletes someone, they leave the organisation. Its plan and policy stop applying to them at their app’s next licence refresh. The owner is never removed this way: hand ownership on first. People you invited by hand are left alone until the directory lists them.

• New directory token gives a new token, and the old one stops working.
• Turn off directory sync stops the token and withdraws the directory’s waiting invitations. Members stay.

Deploy Cuewire

On Windows, Cuewire installs per user, without administrator rights. To deploy it with your device management (for example as an Intune Win32 app installed in the user’s context), run:

CuewireSetup-<version>-x86_64.exe --silent

It installs into the user’s %LOCALAPPDATA%\Programs\Cuewire. It registers a quiet uninstall command (uninstall.exe --uninstall --silent) under the entry com.cuewire.desktop. Use that entry to detect the install. Installed this way, Cuewire updates itself.

A policy for this computer

You can also set a policy per computer. Put a managed-policy.json in the machine-wide folder, for example with your device management:

Cuewire reads it when it starts. Every field is optional. Leave a field out to allow anything:

{
  "allowed_presets": ["claude_code", "codex"],
  "allowed_models": ["sonnet", "opus"],
  "sandbox_required_for_skip": true,
  "remote_hosts": ["*.corp.example", "wsl:Ubuntu"],
  "update_channel": "stable",
  "max_telemetry": "heartbeat",
  "forbid_raw_input": true
}

With a Team plan, your organisation’s policy arrives with each person’s licence. The two are combined: whatever either forbids stays forbidden.

Warning

A file that is there but can’t be read blocks agents, remote projects and telemetry until it is fixed. Cuewire says why where something is refused.

The agents’ own managed settings

Cuewire honours the settings you deploy for the agents themselves. It never asks an agent for what they forbid.

Settings an agent gets from its own service or from device management (registry, configuration profiles) are applied by the agent as usual. Cuewire reads only the files. A file Cuewire can’t parse restricts nothing on Cuewire’s side, because the agent itself still enforces it. Agents on a remote host follow that host’s settings.

The audit log

Cuewire keeps a record of security-relevant actions in audit/audit.jsonl in its state folder:

• agents started, with whether they skipped permission prompts or were held read-only;
• launches and remote hosts a policy refused;
• sign-in and sign-out, settings sync, telemetry choices and role rules;
• companions paired and unpaired, and what a companion approved or prompted (never the prompt’s text);
• what orchestrator agents changed on the canvas: agents recruited (with their agent and role), dismissed or wired together, notes added, portals opened (with their address).

Beside it, audit/host.jsonl is written by the background service that runs the agents. It holds every task one agent handed another (who to whom, never the prompt), and every raw keystroke input one agent typed into another’s terminal.

A remote Linux host keeps its own log, in ~/.local/share/cuewire/audit/host.jsonl there. The computer that drives it keeps a copy in audit/remote/. It fetches the copy when it connects and every ten minutes after, and exports and sends it with its own logs.

Each record holds the hash of the one before it. So a changed, removed or reordered record shows.

Export the audit log

Press Ctrl+K and choose Export audit log…. Cuewire checks each log’s chain and saves copies, as JSON lines, to your Downloads folder, for your SIEM. It then says, for each log, how many records it saved and whether the chain is intact.

Send it to a collector

To have every computer send its log to your OpenTelemetry collector (or any service that takes OTLP/HTTP JSON logs), add audit_export to managed-policy.json:

{
  "audit_export": {
    "otlp_logs_url": "https://otel.corp.example:4318/v1/logs",
    "headers": { "x-api-key": "…" }
  }
}

• Each record becomes one log record. Its action is the body, and its fields are attributes named cuewire.<field>. cuewire.audit.log says which log it came from (app or host). cuewire.audit.seq, cuewire.audit.prev and cuewire.audit.hash come with it, so you can check each chain on your side. Refusals are WARN; everything else is INFO.
• The resource names the app (service.name = cuewire, service.version), the install (service.instance.id) and the computer (host.name).
• New records go within seconds. If the collector is down, Cuewire keeps them and tries again, waiting up to 15 minutes between tries. So none is skipped. A new URL gets the whole log.
• The URL must be https://. Plain http:// works only to the computer itself.

Note

Cuewire reads audit_export only from the computer’s own file, never from a Team licence, because its headers may hold a key.

What’s next

• Teams and organisations: seats, invitations and roles.
• Privacy and security: what Cuewire sends and keeps.
• Sandboxes and safety: sandbox profiles for agents.