# IT & governance

> How access works in Helix today: organization roles, workspace membership, per-app access control, credential aliases, and the org-wide activity trail.

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](/documentation/concepts/security-model/), then read this page for the access model and [the Admin console](/documentation/governance/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](/documentation/governance/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.

:::note{title="Role capabilities are being confirmed"}
The table above describes the role behavior visible in the shipped dashboard. The full list of actions each role can and cannot take is still being confirmed with engineering, so treat it as a description rather than a complete capability matrix.
:::

## 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](/documentation/governance/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](/documentation/governance/admin-console/).

:::roadmap{title="Creating authentications in Helix"}
Creating an authentication directly in Helix, rather than in Tray iPaaS, is planned. Today the Tray iPaaS flow is the only way to create one.
:::

## 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](/documentation/governance/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](/documentation/governance/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.

:::roadmap{title="Finer-grained permissions"}
The platform design describes a deeper model: workspace-level admin, editor, and reader tiers, organization policies that project code cannot override, and role rules declared in project configuration. The shipped product has two organization roles and per-project Access Control. Treat the tiered model as design, not as something you can configure today.
:::

## What's in this section

- [The Admin console](/documentation/governance/admin-console/): the org-wide view an admin gets, and what to look for in it.
- [The Helix dashboard](/documentation/governance/dashboard/): the builder view, project tabs, execution logs, and Organization settings.
- [Audit and compliance](/documentation/governance/audit-and-compliance/): the activity trail, execution logs, and the open questions on retention and residency.
- [Identity administration](/documentation/governance/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](/documentation/reference/limits/).

---

Canonical: https://helix.tray.ai/documentation/governance/
Any link on this page is available as markdown by appending .md to its URL.
Full corpus: https://helix.tray.ai/documentation/llms-full.txt