At a glance
The short version: the tool works where your people work, under the controls IT already enforces. No new perimeter to draw.
What stays on your machine
Screenshots, recordings, run evidence, vault credentials, and the documents the agent reads all live on the workstation's own disk. Because that workstation already sits inside your network, the agent inherits your firewall, endpoint protection, access controls, and monitoring.
What leaves the machine
Three flows carry work. A fourth, telemetry, is optional and carries product health only.
| Flow | What travels | Where it goes |
|---|---|---|
| Workflow actions | The submission, email, or upload a person would make anyway | The same third parties, from the same session and IP |
| Model calls | Only the screen region being read, plus one narrow question | The model account you own (OpenAI, Anthropic, Azure, Bedrock) or a model you host |
| Portal sync | Run status, review outcomes, rules and tables, device heartbeat | Your organization's LaunchAI portal |
| Telemetry (optional) | Product health and version | LaunchAI |
A workflow decided entirely by exact rules can finish with zero model traffic. Point the setting at a self-hosted model and nothing crosses your perimeter.
Signing in without knowing passwords
- Step 1
Stay logged in. The agent works inside sessions you already opened. It never meets a login screen, so it never types or stores a password.
- Step 2
The vault, when you can't avoid it. Credentials go into an encrypted vault backed by the operating system's keychain. Workflows name an entry and never hold the value. Values are masked in every log, screenshot, and recording.
- Step 3
MFA stays on. When a portal asks for a code, the run waits, a named person types it, and the run continues. Codes are never stored.
Least privilege, enforced
Each workflow is fenced. A workflow declares the apps, folders, and databases it may touch. Anything else is refused before it reaches the screen. An AP workflow can't open payroll, even if an invoice tells it to.
Each person holds separate rights. Build, Approve for production, Edit rules and tables, Review, Run, View history, and Manage credentials are seven separate permissions. The backend enforces them, and every change is logged.
Tenants, devices, and step-up. Each company or client gets its own tenant. Only enrolled machines run agents, and revoking one stops them. Sensitive actions can demand a fresh sign-in.
Try it: who holds what?
| Permission | AP clerk | Controller | IT lead |
|---|---|---|---|
| Build | |||
| Approve for production | |||
| Edit rules and tables | |||
| Review | |||
| Run | |||
| View history | |||
| Manage credentials |
Separation of duties: now holds both Build and Approve for production. Keep the two rights with different people.
Threat model
Threat: A doctored PDF or web page tries to redirect the agent Our control: Screen text is treated as data; money decisions run on exact rules; the workflow fence refuses other apps Your part: Place a review step before posting and payment
Threat: A fake supplier asks to change bank details Our control: Review step with a call-back to a number on file Your part: Write the call-back policy
Threat: An insider edits a payment workflow Our control: Build and Approve are separate; approved versions are read-only and versioned Your part: Keep the two rights with different people
Threat: A laptop is stolen Our control: Revoke the device and its agents stop; vault entries are encrypted Your part: Full-disk encryption and screen lock
Threat: Someone tries to cover their tracks Our control: Records are append-only and hash-chained per run Your part: Set retention so evidence outlives questions
Threat: An impatient double-click on Run Our control: Each run request carries its own idempotency key Your part: Give writing steps a business key the ERP checks
Joiners, movers, leavers
Workflows, tables, and evidence belong to the tenant, not the person.
- grant only the rights the role needs
- add them to review assignments
- name vault entries for the system, not the person
- remove old rights before adding new ones
- move review assignments
- rotate vault entries they no longer need
- remove rights
- revoke their device
- rotate vault entries
- move scheduled workflows to another machine and supervise the first run
Once a quarter, confirm who holds Approve, Edit rules and tables, and Manage credentials.
If something goes wrong
Stopping isn't rolling back. A posting that landed stays posted, and reversing it is a person's call in the ERP.
-
Stop
Abort the run, pause the schedule, revoke the device, or remove a person's rights. Pick the smallest stop that contains it.
-
Investigate
Open the run, trace the bad value to its source, check which version ran and who approved it.
-
Rotate
Change affected vault entries, account passwords, and your model key.
-
Restore
Roll back to the last good version, get it approved, and supervise the next run.
Your model provider, your settings
The model account is yours, so its retention and training terms are yours to set.
- OpenAI
- Anthropic
- Azure
- Bedrock
- self-hosted
- Create a dedicated project or workspace for LaunchAI
- Request zero retention where the provider offers it
- Pin the region your data-residency policy requires
- Keep regulated workflows on a self-hosted model or exact rules only
What we don't claim
- No certification claims on this site. Ask for current attestation status during your review.
- No accuracy or uptime percentage.
- No guarantee a portal will never show a captcha.
Security questionnaire
Does LaunchAI receive our business data?
Is our data used to train models?
Could a malicious document redirect the agent?
Who can see screenshots of our screens?
How do we tell the agent's ERP entries from a person's?
Does it install a browser extension or inject scripts?
What does support see?
No question matches. Try another word, or ask in your review.
For the architecture behind these controls, see Engineering.
Inside Trust
No prompts. No babysitting. No Integrations.