> For the complete documentation index, see [llms.txt](https://docs.atomyx.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.atomyx.io/getting-started/security-access-and-governance.md). # Security, Access and Governance This page provides a high-level view of how security, access control, and governance work across the platform. ### Identity and authentication Atomyx uses **Atomyx Vault** as the shared identity and access layer across the platform. Vault is responsible for: * user authentication * workspace membership * product access * subscription-aware access control * API key management Users sign in with their own account and can belong to one or more workspaces, depending on their role and responsibilities. ### Workspace isolation Workspaces are the main isolation boundary in Atomyx. Each workspace is separate in terms of: * users * products * subscriptions * configuration * integrations * operational context This separation is important for: * development vs production environments * staging and QA validation * multi-region operations * different teams, customers, or business units ### Layered access control Atomyx access is layered rather than flat. A user typically needs: 1. an Atomyx account 2. membership in a workspace 3. access to one or more products in that workspace 4. the correct role at workspace and/or product level Being added to a workspace does not automatically grant access to every product inside it. ### Roles and permissions Atomyx uses role-based access control at more than one level. #### Workspace roles Typical workspace roles include: * Owner * Admin * Member * Billing These control things such as: * workspace settings * user management * group management * product administration * subscription and billing access #### Product-level roles Products may also define their own access levels. This allows a user to have one level of access in the workspace and a different level inside a specific product. ### Group-based access Groups help manage access at scale. Rather than assigning users individually across every product, teams can: * organise users into functional groups * assign groups to products * manage access more consistently over time This is generally a better long-term approach than managing every product assignment one by one. ### API security API access is authenticated using API keys. Good Atomyx API key practice includes: * using separate keys for development, staging, and production * storing keys securely in environment variables or a secrets manager * rotating keys regularly * replacing keys immediately if compromise is suspected * never exposing keys in browser-based client code * never committing keys to source control ### Account security For accounts with administrative or sensitive operational access, stronger account security should be used. Recommended practices include: * using individual accounts, not shared logins * keeping profile details current * enabling two-factor authentication where available * reviewing who has Owner or Admin access regularly ### Governance principles Atomyx works best when platform governance is handled deliberately. Recommended governance principles include: #### Least privilege Give users the minimum access they need to do their work. #### Environment separation Keep development, staging, and production clearly separated through workspaces, products, keys, and integrations. #### Traceable ownership Ensure it is clear who owns workspace setup, billing, integrations, and operational administration. #### Regular access review Review user roles, group membership, and product access periodically. #### Controlled integration setup Document external integrations, callback endpoints, and product-level credentials so they can be maintained safely. ### Practical implementation advice When setting up Atomyx for real use: * start with a clean workspace structure * separate non-production from production * define who owns workspace administration * define who owns billing * define how product access is granted * define how API keys are generated, stored, and rotated * avoid treating access and integration setup as ad hoc tasks ### Where to go next If you need more detailed guidance, continue with: * **Shared Concepts > Roles and Access** * **Vault > Users, Groups and Roles** * **Vault > Products and Subscriptions** * **Vault > Authentication and API Keys** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.atomyx.io/getting-started/security-access-and-governance.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.