Security
Your company’s apps start company-only.
A new app is available to workspace members. Outside access is a separate decision. People, agents, and connected apps follow the same current permission checks.
Sharing an app should be a deliberate choice.
Select a smaller coworker audience for a sensitive app. Invite a guest to one app by verified email. Choose which actions they can use. Revoke the grant when the work is done.
Guest grants add access; they do not remove existing workspace access. Review the app audience and public publishing settings when a review needs to stay restricted.
Enforced
- verified sessions
- current workspace access
- action permissions
- private app runtime
- Library source permissions
Not public
- app actions
- company Library
These checks apply to browser, CLI, MCP, and app requests.
01Verified peoplePeople verify their email to sign in. Browser, CLI, and named agent sessions identify the person responsible for the request.
02Current accessAtrax checks current workspace membership, app audiences, and action permissions before work runs. Delegating a call to another app preserves the person's restrictions.
03App isolationUploaded code runs behind Atrax's gateway. It receives its own resources and limited permission for the current request. Platform credentials stay outside the app.
04Company knowledgeLibrary checks access before returning search results or file contents. It stores company knowledge, not API keys, credentials, or secrets; shared credential management is planned separately.
05Public publishingAn admin can publish an app's web assets publicly. That does not make its actions or company Library public.