Same-workstation runtime
Content-processing location: the user’s workstation.
Authorized user→Bridge Desktop→localhost runtime
Security architecture
Know where the work runs—and what crosses each boundary.
Security starts with deployment choices you can name: the model endpoint, the hardware owner, the approved tools, and the people and devices allowed to connect.
Bridge Mobile access does not determine where inference occurs. It is a separate, authenticated access path to Bridge Desktop.
01 / Deployment boundary
Choose the model path before evaluating the access path.
Selected cloud model. Content routed to a cloud model follows that provider’s approved boundary.
Customer-controlled private model. Inference runs on a suitable workstation or server the customer controls.
Alluqi-managed dedicated model. Inference runs off-site on separately contracted dedicated infrastructure; traffic leaves the customer network.
02 / Data paths
Five ways to place the same working surface.
Each example identifies the content-processing location. Hosted metadata and the optional encrypted relay remain separate from the model endpoint.
Customer-network model server
Content-processing location: the customer-controlled network.
Bridge Desktop→Private network IP→Ollama or vLLM server
Alluqi-managed dedicated server
Content-processing location: separately contracted off-site infrastructure.
Bridge Desktop→Encrypted network path→Dedicated model server
Selected cloud model
Content-processing location: the approved cloud provider.
Bridge Desktop→Provider API→Cloud model
Deliberate hybrid routing
Content-processing location: the endpoint selected for each approved workflow.
Bridge Desktop→Private or cloud route→Approved model
03 / Hosted boundary
Metadata for connection. Not working content.
The hosted service needs enough account and connection information to authorize endpoints. Its design boundary is intentionally narrower than the work flowing between them.
Hosted metadata may include
- Account metadata
- Host and device metadata
- Pairing and relay metadata
- Audit metadata
Designed not to store or log
- Prompts or responses
- File contents or paths
- Terminal output or screenshots
- Approval payloads or command content
- Credentials or private keys
- Session keys or browser/computer-use state
04 / Identity + remote access
A signed-in account is not the same as remote authority.
01
Passwordless identity
The inspected hosted account source supports an emailed sign-in code. Google sign-in is planned and is not currently offered on this site.
02
Account-only mobile state
A mobile user may sign in to basic account screens before enabling 2FA.
03
Authenticator-app TOTP
The public remote-access release requires authenticator-app TOTP before pairing a PC or viewing sessions, files, responses, or controls.
04
Recovery and revocation
Recovery codes provide a one-time fallback. Pairings, devices, and remote authorization must be revocable.
05 / Relay + permissions
Encrypted transport does not grant a model permission.
Relay boundary. The hosted relay is designed to forward opaque encrypted traffic between approved endpoints without deriving the phone-to-host content keys.
Tool boundary. A model does not automatically gain access to the whole computer, every file, terminal command, browser session, or business system.
Operational boundary. Explicit tools, working directories, user approvals, model choice, local backups, infrastructure access, and incident response remain part of customer responsibilities.
06 / Compliance boundary
Architecture supports a review. It does not replace one.
Alluqi can be configured around customer-selected infrastructure and security requirements. Compliance depends on the complete deployment, contracts, policies, controls, and operating practices. Alluqi does not claim a certification or authorization unless it is named here with current evidence.