Privacy at Infser
Infser keeps the control plane focused on identity, authorization, device state and security metadata, while limiting stored runtime content by design.
Last updated: October 18, 2026
Project scope
Infser is an independent software project. This document describes the project’s current data-processing model and the public contact path without inventing a registered-company identity.
Account and authentication data
Infser processes account identifiers, email, password-security state, verification state, two-factor metadata and connected authentication identities when applicable so users can authenticate and secure access.
Workspace and membership data
Workspace names, memberships, roles, invitations and permission relationships are processed to isolate tenants and decide which users may access devices and actions.
Device and runtime metadata
Device identity, public-key or fingerprint metadata, platform, agent version, reported capabilities, lifecycle state and recent presence are processed to route only authorized work to eligible devices.
Action, approval and security metadata
Infser records bounded operational metadata such as actor, target, action status, approval decisions, timestamps and security events so authorization can be enforced, revoked and audited.
Execution-content boundary
Runtime content is processed only as needed for the requested feature. Terminal sessions are designed not to become stored command transcripts, while temporary artifacts and isolated browser execution use bounded lifetimes where supported.
Security and abuse prevention
Authentication, rate limits, tenant isolation, device lifecycle checks, revocation and audit signals are used to protect accounts, workspaces and infrastructure from unauthorized access or misuse.
Service-provider categories
Depending on active production configuration, infrastructure hosting, email delivery, authentication or payment providers may process the minimum data needed to provide their function. Infser does not invent a fixed provider list when a service is not configured.
Retention principles
Account and workspace records are kept while needed to operate the relationship. Security and audit records may outlive a session where needed for traceability, while short-lived grants, tokens and temporary artifacts follow bounded expiry or cleanup rules.
Your choices and requests
Users can manage profile and security settings, revoke connected access, disable or revoke devices, and request account deletion subject to workspace-ownership and security constraints. Privacy questions or requests can be raised through the project contact path.
Contact about privacy
Use the Infser Contact page for privacy questions. Do not post passwords, tokens, private keys, sensitive machine data or identity documents in a public repository issue.