Enterprise fit
How AskUI fits into your environment, what runs where, what leaves your network, what is stored, what gets downloaded, and what IT has to approve.
Everything here answers one question: what does bringing AskUI into your environment actually mean? The short version, screenshots of your applications go to an AI model for the agent's decisions; everything else (testware, reports, secrets) stays on your machines.
Straight to your questions:
| If you are | Start at |
|---|---|
| A software architect | The four components, What talks to what, Concurrency and upgrades |
| IT security | What leaves the network, What the agent may do on a machine, Telemetry, Inbound ports, hardening a run |
| Compliance | Data protection, What is stored where, What is downloaded at runtime |
| The team running the lab | Running the lab machines, Infrastructure requirements |
The full picture, in the order a review usually asks for it:
Start simple: one computer
The smallest setup is one machine: AskUI Desktop and the application under test side by side on the tester's PC, with the project, tests, prompts and reports, in a folder next to them. The only thing that leaves the machine is the inference traffic: the screenshot, the step text and the conversation of the current test:
The model provider is the AI service that makes the agent's decisions: the AskUI hub by default, or one you bring yourself, the choice, and what it means for your data, is in What leaves the network.
Nothing to provision, no server, no CI: install, sign in, write a test, run it (first run). Most teams stay here for their first weeks.
Expand to scale
When tests should run without a tester present, the same project moves outward in three steps, each one optional and independent. The AskUI CLI runs it headless, the same way Desktop does interactively:
Every box is one real thing you provision, and every group is optional: VMs at your cloud provider, machines in your own lab, a rack of phones and simulators. Browsers are the exception, they need no machine of their own: Playwright runs on whichever machine started the run. Desktop and the CI pipeline drive the same targets from the same project, so a test written on a tester's PC runs unchanged in the pipeline.
- Remote test machines: the application under test moves off the tester's PC onto dedicated machines running AgentOS, so a run can't disturb anyone's desktop and several tests can run at once.
- The project in Git: the same folder for everyone, reviewed like code (versioning).
- CI pipeline: the CLI runs the same project headless on every merge or on a schedule, against the same machines (AskUI in CI).
Who owns which part of that setup: Sharing the project.
The four components
A raw CUA can drive a screen. Turning that into test automation an enterprise runs every day, on its own machines, inside its own network, under its own governance, takes four things, and each one runs somewhere you control:
| Component | Role |
|---|---|
| AskUI Desktop | Where you author, run, and review, projects, devices, reports |
| AskUI CLI | The same runs, headless, CI and scheduled execution |
| AgentOS | Gives the agent eyes and hands on a machine: screen, keyboard, mouse, details |
| AskUI Hub | Workspace, members, tokens, billing, account |
Where each one runs, what it talks to, and what it stores follows below; the enterprise questions, proxy, air-gapped operation, CI runners, are in Infrastructure requirements.
What talks to what
| Connection | Protocol | Notes |
|---|---|---|
| Desktop/CLI → AgentOS | gRPC, port 23000 (app-spawned) or 26000 (installed service) | Screen, keyboard, mouse of a desktop machine |
| Desktop/CLI → browser | Playwright, local | Web profiles, no AgentOS involved |
| Desktop/CLI → Android | adb, local/USB/wireless | Emulators and phones |
| Desktop/CLI → model provider | HTTPS | See below, the only place test content leaves your network |
| Desktop → AskUI Hub | HTTPS | Sign-in, tokens, usage. Not involved in test execution itself |
Read the first row as an inbound port on the target machine: AgentOS listens there, and Desktop or the CLI connects in. Nothing else in the picture listens; every other arrow is outbound from the machine that starts the run. Restrict the AgentOS port to the machines that are allowed to drive tests.
Endpoints and firewall rules: Network requirements.
What leaves the network (and how to stop it)
Each loop iteration sends the current screenshot, the step's text and the conversation so far (earlier screenshots, decisions and tool results of this phase) to the model provider. That is the inference the agent's decisions are made of, and the only test content that travels at all. Where it travels is your choice:
- AskUI hub (default), inference runs through us, billed with your workspace.
- Your own cloud tenancy: with BYOM the traffic goes to an endpoint you own instead, so it stays inside contracts and a cloud account you already hold. This is what most IT-security reviews approve. Your Anthropic account, Azure AI Foundry and gateways behind Microsoft Entra work out of the box. AWS Bedrock, GCP Vertex AI and internal gateways with their own authentication scheme need that scheme implemented, so if your models sit behind one, talk to us, we support you in getting it wired up.
- On-premise inference: point BYOM at a vision model you host yourself (vLLM, SGLang) and nothing leaves your network at all. If you don't have the hardware for it, we can supply a local deployment on NVIDIA hardware you purchase, talk to us.
What the agent may do on a machine
The blast radius is the toolbox, not the machine. The agent can only act through tools it was given, and you decide which:
- Screen, keyboard, mouse come with the device and are always there. Within a session the agent can do what the logged-in user can do.
- Reach beyond the UI is opt-in: the shell, SQL and file tools in the
Tool Store are off until someone enables them,
and enabling them is recorded in
utils/tools.jsonin the project, so it shows up in review. - Custom tools are code: a
.csfile inutils/custom_tools/runs with the permissions of the run, which is why they belong to developers and get reviewed like any other code in the repository. - Elevation is a deliberate switch: without "Allow control of administrative applications" the agent cannot drive elevated windows.
- Credentials never reach the model: steps reference secrets by name, values are substituted at execution time and redacted from reports and logs.
How to keep that reach as small as a test needs, account rights, scoping each tool, what belongs in review: What the agent may do.
Telemetry, what we see
- The hub sees sign-in, tokens and usage counters for billing, not your test content (usage dashboard).
- Model traffic goes to the provider you chose, and only that provider, see above.
- OpenTelemetry tracing is off by default. It exists for teams that want
traces in their own collector and is enabled explicitly with
ASKUI__OTEL_*environment variables, pointing at an endpoint you own. - Reports and screenshots stay local, in the project folder. Nothing uploads them anywhere.
Data protection
- Test content that travels is limited to what the model provider needs for inference: the screenshot, the step text and the conversation of the current phase. Nothing else is transmitted, and with on-premise inference not even that.
- Screenshots can contain personal data if your test data does. That is a processing decision on your side: choose the provider placement accordingly, and prefer synthetic or anonymised test data.
- Evidence lives with you: reports, screenshots and the conversation log are files in your project, so your retention and deletion rules apply unchanged.
- DPA, retention at the hub, hosting region, and whether a provider trains on inputs depend on the provider you choose and your contract with us: ask us for the current documents rather than assuming.
What is stored where
| Data | Location |
|---|---|
| Testware, tests, procedures, plans, rules | The project folder, plain files, yours to version |
Agent files, the prompts/ folder, tool and device configuration | Same folder, versioned alongside the testware |
| Test evidence, reports, screenshots, logs | agent_workspace/ inside the project, local |
| Credentials for tests | The app's secret store, encrypted with your Windows/macOS user account, never in the project |
| Sign-in tokens | Encrypted local storage on your machine |
What is downloaded at runtime
For supply-chain review, the app fetches on demand, each after an explicit
action on your side: browser bundles (first
web-profile connect), the Android SDK toolchain
(consent click on Set up), NuGet packages
declared by your custom tools (resolved via
your own NuGet.config, so enterprise feeds and mirrors apply), and
connections to the MCP servers your project registers.
Running the lab machines
What the team providing the machines needs to know:
- Interactive session required. The agent works on a real desktop
session: a locked screen or a machine with no session has nothing to
drive, and a run against it ends as
BROKEN. Keep sessions unlocked and screensavers/sleep disabled on test machines. - Service or standalone. AgentOS can run as an installed Windows service (port 26000, starts with the machine, survives reboots, the choice for shared lab machines) or be started by the app on demand (port 23000, fine on a tester's own PC).
- Elevation. Driving elevated windows requires enabling "Allow control of administrative applications" during installation.
- Sizing. Requirements per machine, including what a VM needs: system requirements. No GPU is needed on the test machine, inference happens at the model provider.
- Health. The Devices page shows connection state per profile before a run; when a machine misbehaves, the symptoms and checks are in Connection & sessions.
Concurrency and upgrades
- One run drives one device profile at a time. Parallelism comes from starting more runs: several CI jobs, several machines, or a multi-computer profile when one agent should hand over between machines inside a single test.
- Project files are versioned and migrate forward. Device profiles and tool configuration carry a version and are migrated on first save by a newer app; renamed or removed built-in tools are mapped automatically. Because everything is a plain file in Git, an upgrade shows up as a diff you can review.
Infrastructure requirements
| Question | Answer |
|---|---|
| Operating systems | AskUI Desktop: Windows and macOS. AgentOS on target machines: Windows 10+/Server 2019+, macOS 10.15+, Ubuntu 18.04+, full matrix |
| Proxy | A system/corporate proxy is supported app-wide (Settings → Network proxy), including NTLM/Kerberos authentication, covers sign-in, model provider, and MCP traffic. Network proxy |
| Air-gapped / no AskUI account | License-key mode removes the hub from the picture entirely: activate locally, bring your own model endpoint. Runtime downloads (browsers, Android SDK) still need a reachable mirror or pre-provisioned tooling |
| CI runners | The CLI authenticates via ASKUI_WORKSPACE_ID / ASKUI_TOKEN. Headless browser targets run on a bare runner; desktop targets need a machine with AgentOS and a real session |
| Team rollout | Which teams run what, and on whose machines: Sharing the project |
Test automation harness
What the harness does on every run, phases, lifecycle files, attempt limits, reports, and why the same test can take a different path.
Sharing the project
How a project is shared across a team, what travels in the repository, what each member adds locally, who owns which part, and where the repository lives.