Helix separates two questions: who can build and deploy apps, and who can use a published app. Building runs on workspace membership plus your organization role. Using a published app is controlled per project, on that project’s Access Control tab, and every published app sits behind a login.
Evaluating whether Helix is safe to run? Start with the security model, then read this page for the access model and the Admin console for what an org admin can see.
Two layers of access
The two layers are governed separately, and a person can sit in one without the other.
| Layer | Governed by | Covers |
|---|---|---|
| Building and deploying | Workspace membership plus your organization role | Projects, deployments, logs, and authentications |
| Using a published app | The project’s Access Control setting | The deployed app at its own URL |
Someone can be granted access to a published app without belonging to the workspace that built it, and without ever opening the dashboard. That is the normal case for the people an app is built for.
Published apps always run behind login
Every deployed Helix app requires sign-in. A visitor has to be a user in your Tray organization, and has to have been granted access to that specific project. There is no public mode, no anonymous mode, and no code a builder can write that turns authentication off.
This is the property most worth checking first when you assess Helix: an app built by a business team in an afternoon cannot accidentally end up on the open internet.
Organization roles
An organization has two roles: Admin and Contributor. You manage them under Organization settings, on the Members tab, which lists each person’s name, email, role, status, and how many workspaces they belong to.
| Role | What it means today |
|---|---|
| Admin | Sees the Admin button in the dashboard header and the org-wide Admin console. Counts as a hidden member of every workspace, so an admin can reach any project. Can set a project’s access to Organization. |
| Contributor | Builds and deploys in the workspaces they belong to. No Admin button, no Admin console. |
Below the organization sit workspaces, and inside workspaces sit projects. Workspace membership decides which projects you can open, build in, and deploy.
Who can use a published app
Each project has an Access Control tab with one setting that decides who can open the deployed app.
| Setting | Who can open the app |
|---|---|
| Workspace | Everyone in the project’s workspace. This is the default. Org admins are included as hidden members. |
| Only people invited | Only the people invited by name. |
| Organization | Everyone in your organization. Only an org admin can select this. |
Invitations are not limited to the workspace. Anyone in the organization can be invited to an app, even if they cannot see the project that produced it or the workspace it lives in. This differs from Tray iPaaS, where access follows workspace scoping, so do not assume your existing iPaaS workspace boundaries carry over.
For the membership model behind these settings, see identity administration.
Credentials never enter code
A Helix project refers to a credential by an alias, a short name such as salesforce or slack. At runtime, Helix resolves the alias to a Tray authentication and attaches the credential to the outbound call.
Three consequences matter for a security review:
- The secret is never written into project source, so it cannot be committed to a repository.
- Claude never sees it. The agent writes code against the alias, and the value is attached after the code is out of the agent’s hands.
- Rotating or replacing the credential behind an alias needs no code change and no redeploy of the calling logic.
Authentications are created in Tray iPaaS today and linked into Helix projects. Each carries a type, OAuth 2.0 or API Token, and the scopes it was granted. Admins can see every authentication in use across the organization in the Admin console.
What gets recorded
Every administrative action in the organization lands in an org-wide activity trail, with the action, who performed it, which workspace it happened in, and when. The recorded actions are:
- Deployed a project
- Created a project
- Deleted a project
- Granted access to a project
- Changed access settings for a project
- Created an authentication
- Deleted an authentication
- Changed a role
The activity trail covers administration. Per-request execution detail lives separately, in each project’s Logs tab. See audit and compliance for the difference and for what is still being confirmed about retention and export.
What an admin can see
Org admins open the Admin console from the Admin button in the dashboard header. It collects, across every workspace, the projects that exist, what they connect to, who they are shared with, recent deployments, the activity trail, and every authentication in use. See the Admin console.
The console shows you what happened. It does not block actions before they happen, so treat it as a review surface rather than a set of enforcement controls.
What’s in this section
- The Admin console: the org-wide view an admin gets, and what to look for in it.
- The Helix dashboard: the builder view, project tabs, execution logs, and Organization settings.
- Audit and compliance: the activity trail, execution logs, and the open questions on retention and residency.
- Identity administration: org membership, workspace membership, and per-project app access.
Organization policies, org-level middleware, AI Gateway governance, and agent guardrails appear in Helix platform design material. None of them are in the product today, so this section does not cover them. What an org admin can actually see and control is in the four pages above; for the full picture of what is and isn’t shipped, see limits and roadmap.