Three common deployment boundaries
LoneAct deployment is not a choice between everything in the cloud and everything offline. Typically you place the LoneAct service where the data lives and use the cloud only for accounts, device discovery, and access grants.
Local / private service
Projects, conversations, teams, memory, and secrets stay on machines or private infrastructure your organization controls.
Cloud account service
Handles accounts, device ownership, remote access grants, online status, and necessary audit records.
Model services
Uses organization-approved providers, regions, and own-key routing; model requests follow provider agreements.
Identity, authorization, and audit
The current version centers on LoneAct accounts, activation codes/plans, device ownership, project authorization, and access grants. Administrators control who can use which project and which capability through these boundaries, rather than relying on an implicit super account.
| Control point | What it does | Recommendation |
|---|---|---|
| LoneAct account | Sign-in, plan, activation code, and device-side identity | Issue one per member; do not share personal accounts |
| Activation code / plan | Carries quota, validity period, and product entitlements | Allocate by team or project and check balance and expiry regularly |
| Device | Identifies which computer owns a project folder and whether it is online | Register only controlled devices and remove them promptly when people leave |
| Project / Grant | Limits visible projects, capabilities, and validity period | Least privilege, short-lived grants, revoke when done |
| Audit | Records grants, administrative actions, and relay events | Export and retain according to organization policy |
This document describes only the account, activation code, device, and access-grant mechanisms that exist today. Whether organization-level SSO, SCIM, fine-grained RBAC, or compliance certifications are available depends on the deployed version and your commercial agreement.
Model egress and data residency
Local-first business data does not mean model requests stay off the network. When an Agent processes a task, the current context is sent to the configured model service; when you use MCP or connectors, related requests may also reach external services.
Model egress
Choose an approved region, provider, and deployment model; prefer private deployments or dedicated connections for sensitive projects.
Service egress
MCP servers, Connectors, and remote tools each have their own data boundary; confirm which data and networks they reach before enabling them.
Local storage
LoneAct stores projects, conversations, teams, memory, and execution records; protect storage directories with your organization's backup policy.
Cloud metadata
The cloud account service stores accounts, devices, access grants, and necessary audit records; it does not copy project files into a second cloud repository.
Pre-launch checklist
- LoneAct deployment location, storage directories, backup, and deletion ownership are clear.
- Model providers, regions, own-key access, and data retention terms are approved.
- Someone owns the issue and revoke process for accounts, activation codes, devices, and access grants.
- Project allowlists, budgets, tool approvals, and audit retention match organization policy.
- A small real project has validated models, tools, secrets, and disconnect/recovery behavior.
- Alternative processes and timelines are defined for capabilities that are not delivered, such as SSO/SCIM.
Next: read Security, permissions, and audit and Data and local-first, then apply the checklist to specific projects and devices.