# AgentSWAT Enterprise Pilot - 0.3.0-pilot.2 Enterprise Pilot adds a self-hosted team service and a Team workspace screen to AgentSWAT Desktop. It is intended for a small, supervised pilot in one organization. Personal workflows, the role library, effort settings and the local Codex integration remain available. ## Start a local pilot 1. Install the Windows desktop application from the delivered installer. It includes its runtime. The installer is unsigned and native graphical launch is still unverified in this build environment. 2. Extract `AgentSWAT-Enterprise-Pilot-Server.zip` into a normal development folder. Install Node.js 24 or later on the server computer. The server bundle is already compiled and needs no npm dependency installation. 3. In the extracted server folder, run: ```sh npm run pilot:setup npm run pilot:start ``` The Windows server bundle also includes `Start-Pilot.cmd`. On first use, setup creates `.pilot-data/pilot.env` and prints a first administrator token. Save that token privately. Setup refuses to overwrite an existing configuration. The initial token expires 30 days after the first server start. 4. In the desktop app, open **Team workspace**. Enter `http://127.0.0.1:4319` and the administrator token, then connect. Session-only sign-in is the default. **Remember on this device** uses the OS credential store. 5. Under **Members**, create individual accounts for designers, operators and reviewers. Give each person their own token through your organization's private channel. No invitations or emails are sent by the app. 6. Under **Models & policy**, configure a shared provider connection using your organization's model ID and API key. A preview can run without a provider connection. The server remains running in its terminal. Closing the desktop client does not stop shared jobs. Use Ctrl+C in the server terminal for a graceful shutdown. The pilot does not install a Windows service or launch daemon. From the full source archive, run `npm ci` and `npm run build` before setup/start. `npm run pilot:smoke` checks the standalone service using temporary data and preview outputs; it makes no model calls. ## Workspace permission roles Agent job titles define the AI's assignment. Workspace roles govern people, and the server enforces them on every request. | Capability | Admin | Designer | Operator | Reviewer | Viewer | | --- | --- | --- | --- | --- | --- | | Read shared versions, runs and member directory | Yes | Yes | Yes | Yes | Yes | | Submit workflow versions | Yes | Yes | No | No | No | | Preview a version | Yes | Yes | Yes | Yes | No | | Start/control live runs | Yes | No | Yes | No | No | | Review workflow versions and live outputs | Yes | No | No | Yes | No | | Read/verify/export audit pages | Yes | No | No | Yes | No | | Manage members, models and policy | Yes | No | No | No | No | The workflow author cannot approve their own version. The member who queues a live run cannot approve its outputs, including when that member is an administrator. A member with preview permission can approve/control their own preview. Demoting that person to Viewer removes that permission. These are individual bearer-token accounts, not SSO or externally verified identities. Operationally assign review accounts to different people; an administrator controls membership. Every member can read all shared briefs, outputs and role instructions. This pilot does not provide private projects, tenant isolation or group-scoped data access. Shared-workspace controls do not govern personal desktop workflows or local Codex file permissions. ## Submit, review and execute 1. Build a team in **Agent library** or **Workflow map**, including assignments, effort, branches, retries and checkpoints. 2. Open **Team workspace > Workflows**. Choose a shared team model. Expand **Models for individual agents** for per-step overrides. Local provider credentials are not uploaded. 3. Choose **Submit version for review**. The service saves an immutable version containing the workflow and the custom roles it uses. A SHA-256 content digest identifies the reviewed snapshot. Concurrent edits are rejected if their expected revision is stale. 4. A different reviewer opens **Inspect version**, checks the graph and complete brief/assignments/role instructions, then approves or rejects it with an optional note. Editing creates a new draft version; it does not change a reviewed version. 5. An operator queues a live run of an approved version. Shared runs continue on the server. The queue accepts duplicate submissions with the same request ID only once. 6. Reviewers approve pending live outputs in **Shared runs**. Run controls include pause, stop, resume and approval. Text and JSON exports exclude credentials. The service has one worker and can overlap up to four API agents within its active workflow. A paused run or run awaiting review releases the worker for another queued job. Resuming while another job owns the worker returns a clear busy message. Only unstarted queued jobs resume automatically after server restart. Interrupted calls remain stopped and require review/manual resume; completed outputs are retained. When final review is required, the service adds checkpoints to terminal outputs. If all terminal paths are skipped, it gates the last completed output instead. A workflow that produced no output can finish with all paths skipped. Optional intermediate checkpoints also require an authorized reviewer for live runs. Shared execution supports OpenAI, compatible APIs, Anthropic, Gemini and Ollama. Codex remains a personal desktop integration because it uses the local account, project and permission dialogs. No remote Codex tools or general remote command runner are exposed. ## Policy and usage limits Administrators set allowed provider types, concurrent agents (1-4), daily runs, daily model attempts, queue depth, output-token ceilings and final-review requirements. Defaults are 100 runs and 500 model attempts per UTC day, 20 queued jobs, two concurrent agents and 16,000 maximum output tokens. Run counts include previews and cancelled submissions; previews consume no model attempts. Attempts count actual provider-call reservations, including failures and retries. These are operational limits, not measured token usage or a monetary budget. Input-token charges and provider-side work may occur even if a call is cancelled. Parallelism and final-review settings are applied when a queued job starts. Provider allowlists, member status, model-attempt quotas and token ceilings are checked before each model call. Revocation prevents new authenticated requests and subsequent model calls; an already submitted external call may finish. Changing/removing a connection invalidates further use of mismatched saved connection settings in a run. Start a new reviewed run if its connection no longer matches. ## Tokens and provider keys Access tokens contain 256 bits of randomness and are stored as SHA-256 hashes on the server. Member tokens expire after 1-365 days, default 30. Administrators can rotate or revoke them. Rotation invalidates the previous token immediately. At least one active administrator must remain when changing roles or active status. Provider keys are encrypted with AES-256-GCM using `PILOT_MASTER_KEY`. Setup stores that master key in `pilot.env`; protect the folder with OS access controls and keep an encrypted backup. The service never sends provider keys back to desktop clients or includes them in audits. Briefs, outputs and membership metadata remain plaintext in SQLite. This is application encryption, not a managed KMS or protection from a compromised server administrator. Master-key rotation is not implemented; changing the key makes existing credentials unreadable. To recover a lost or expired administrator token, stop the server and run: ```sh npm run pilot:recover-admin ``` Recovery verifies the audit chain, rotates the oldest administrator's token, reactivates the account and records an offline recovery event. Keep the newly printed token private. This operation requires access to the server filesystem. It does not recover a lost provider master key. ## Remote HTTPS and deployment The default listener is loopback only. For access from other computers, use a hostname and a valid certificate trusted by those desktops. Add these settings to the private `pilot.env` file: ```dotenv PILOT_HOST=0.0.0.0 PILOT_PORT=4319 PILOT_TLS_CERT_FILE=/absolute/path/fullchain.pem PILOT_TLS_KEY_FILE=/absolute/path/private-key.pem ``` Use quoted Windows paths if they contain spaces. Restart the service and connect desktops to `https://your-hostname:4319`. The server supports direct HTTPS with TLS 1.2 or later. It does not issue or renew certificates. Clients reject untrusted certificates and redirects; do not disable certificate verification. Provision a trusted certificate/CA through your organization's normal process. Alternatively, terminate TLS at your existing reverse proxy and keep the Node listener private. Non-loopback plain HTTP requires an explicit `PILOT_BEHIND_TLS_PROXY=true` setting. That flag asserts your deployment arrangement; it does not configure TLS or prevent exposure by itself. Do not publish the plain HTTP listener directly to remote clients. `deploy/Dockerfile` and `deploy/compose.yaml` provide an optional Node 24 container example with a non-root user, private loopback port mapping and a persistent named volume. Build the source first, then run setup and `docker compose -f deploy/compose.yaml up --build`. The standalone server package already contains the compiled bundle. The example does not enable remote access or configure certificates. Docker deployment has not been executed on this build host. The single-worker lock prevents two service processes from running the same workspace. A hard crash may leave `server.lock`. Verify that the recorded process has stopped before removing that specific lock and restarting. Never run multiple replicas against one SQLite directory. Configure any service supervisor to allow operator inspection after a crash, rather than blindly removing locks. ## Audit and backups **Audit record** verifies the stored event chain and exports up to 500 entries per page. Events cover membership and model/policy changes, workflow submission/review, queue submissions, model-attempt reservations, execution checkpoints and run controls. Each entry includes actor ID, sequence, timestamp, previous hash and current hash. Checkpoints hash outputs instead of copying their full content into the audit log. Keep exported pages and their checkpoint hashes in a separately protected location. A full database administrator can rewrite the database and recompute its chain, or restore an old snapshot; verification within the same database cannot detect those cases by itself. This is a verifiable event chain with optional external anchoring, not immutable or certified audit storage. Startup refuses a workspace whose chain does not verify. For a consistent backup, gracefully stop the service, then copy the entire data directory and the private environment/key file to encrypted storage. Container data is in the named volume; its environment file is outside that volume. Restore both together into an isolated location, check any stale lock against its original process, and run the service and audit verification before switching users. Retention, automatic backups, deletion workflows and a restore UI are not implemented. ## Pilot limits and acceptance The UI shows the latest 200 workflow versions and 100 jobs; older records remain in SQLite. Limits include 200 members, 30 shared connections, 30 agents per workflow, four parallel API agents, and one active shared worker. HTTP requests are capped at 2 MB. Member API requests are limited to 300 per minute; failed authentication is throttled by direct socket address. Browser-origin requests and cookie authentication are not supported. Before using real organizational data, complete a supervised desktop/provider trial, verify account assignment and certificate trust, exercise backup/restore, and select operational owners. This release has no SAML/OIDC SSO, SCIM, multi-tenant backend, distributed workers, document retrieval, metered cost reporting, signed desktop builds, automatic updates or independent security assessment. Read VALIDATION.md for what was exercised here.