SECURITY
Atom9 applies security controls across accounts, workspaces, customer apps, AI-assisted work, integrations, files, and approvals. This page explains the security practices users and customers need to follow without exposing internal platform architecture or operational details.
Atom9 does not publish private operational routes, infrastructure paths, private operational endpoints, secrets, or low-level architecture details. Users and customers must use the approved Atom9 product surfaces, documented developer interfaces, and agreed support channels.
Security anchor: users and customers interact through approved product surfaces. Private operational details are intentionally not public configuration material.
This page explains user-facing security responsibilities, product controls, and safe operation. It does not disclose private operational routes, private hostnames, private network topology, deployment diagrams, secrets, key material, or operational runbooks.
Users and customers must access Atom9 through the visible product, hosted login, documented SDKs, documented public API paths, and agreed customer support channels.
Users must not use browser developer tools, logs, copied URLs, guessed routes, direct service calls, or automation to bypass login, session, role, approval, rate-limit, audit, or validation controls.
If a URL, token, host, route, or technical detail appears in debugging output, logs, error messages, network traces, screenshots, or support diagnostics, it is not a supported integration path unless Atom9 documents it as such.
Each person must use their own Atom9 account. Shared passwords, shared mailboxes used as a team login, copied session cookies, or reused passkeys break accountability and are not allowed for normal workspace operation.
Users must keep email accounts, OIDC accounts, passkeys, password managers, recovery methods, and devices secure. Higher-risk workspaces and customer apps can require stronger methods such as passkeys, multi-factor authentication, or approved identity providers.
Users must sign out from devices they no longer control, report suspicious sessions, and avoid using Atom9 on unmanaged or untrusted devices for sensitive work.
Workspace owners must follow least privilege: give users only the access needed for their role, review access regularly, and remove access promptly when a person changes role, leaves a project, or no longer needs access.
Security anchors: Security 3.1 covers workspace ownership, Security 3.3 covers integrations, and Security 3.5 covers customer-app launch safety.
Workspace owners are responsible for team invitations, role assignment, offboarding, customer-app settings, project approvals, connected tools, and the customer data placed in the workspace.
Customer apps must use verified domains, HTTPS, and configured return paths. Customers must not use temporary, copied, or unrelated callback paths for production login or account flows.
Customers must connect only tools they trust, grant the minimum useful permissions, remove unused connections, and rotate credentials when access changes or compromise is suspected.
Customers must not upload malware, stolen data, unrelated third-party data, unnecessary secrets, or files they are not allowed to process. Sensitive imports require a workspace configured for that data type.
Customers must review login methods, roles, data fields, notices, AI explanations, approval gates, emails, forms, automations, and launch checks before a customer app goes live.
Users must follow prompt safety: do not place passwords, private keys, recovery codes, payment card data, health data, financial records, special-category data, or unrelated confidential material into prompts unless the workspace is configured for that processing and the user is authorised to provide it.
Users must review and approve sensitive AI-generated plans, pages, workflows, automations, data requests, and customer-facing changes before they are launched or relied on.
AI-generated output does not override legal duties, security controls, role limits, customer approval, or restricted-data rules. Suspicious AI output must be rejected or escalated.
Regulated, high-impact, financial, health, employment, child-related, identity, safety, or security workflows require stronger review, documentation, human oversight, and launch approval.
Users and customers must report suspected account compromise, accidental disclosure, unsafe AI behaviour, suspicious login, unauthorised access, exposed credentials, or broken access controls through Atom9 support, security, or agreed customer channels.
Reports must include the affected workspace or customer app, time, visible user action, screenshot where safe, and a plain-language description when that information is reasonably available. Reports must not include passwords, private keys, session cookies, or unnecessary personal data.
Users must not test, scan, exploit, scrape, overload, access other people's data, or run intrusive security tools against Atom9 or customer apps unless Atom9 has given explicit written permission for that test. Suspected weaknesses must follow vulnerability disclosure.
Atom9 investigates credible security reports, preserves relevant evidence, limits impact, communicates with affected customers where required, and applies fixes through controlled operational processes.
Atom9 uses authentication, session controls, permission checks, role boundaries, audit records, provider controls, secure configuration, backups, monitoring, incident handling, and security review as baseline controls.
Atom9 treats security as part of planning, design, development, maintenance, vulnerability handling, customer guidance, and operational change management.
Atom9 selects and configures providers, models, integrations, libraries, and infrastructure with attention to service purpose, access control, data location, security, confidentiality, and update responsibility.
Atom9 does not rely on users understanding internal architecture to stay safe. The product must present clear controls, safe defaults, review gates, and plain-language warnings where user action affects security.
Privacy
You can change this later from the footer. Read the Cookie Policy and Privacy Policy.