How access works

Access to a space starts with a role binding: a role granted to a user, IdP group, API key, or stack on a specific space. But the space a binding names is rarely the only space it affects. Three mechanisms reshape where a binding actually takes effect:

• Access propagation carries a binding down to every descendant space.
• Resource inheritance shares a parent's resources into a child and, in return, grants read back up to the parent.
• Implicit stack access gives every stack read access to its own space, and read access up through inheriting parents.

This page explains each one and how it surfaces in the UI. For roles, actions, and how to assign them, see Access control and the RBAC system.

Resident access

The simplest case: a role is bound directly to the space you're looking at. The user (or group, API key, or stack) holds that role on that space, with nothing in between. This is resident access.

Propagation, inheritance, and implicit access all extend a resident binding to other spaces.

Access propagation (down the tree)

A role binding on a space applies to that space and to every space beneath it in the tree, all the way down. Grant someone the Space Admin role on ParentSpace and they are effectively Space Admin in ChildSpace1, ChildSpace2, and GrandchildSpace too.

graph TD
    role{{ Role }}
    parentSpace[ParentSpace]
    childSpace1[ChildSpace1]
    childSpace2[ChildSpace2]
    grandchildSpace[GrandchildSpace]

    role -. Bound to .-> parentSpace
    parentSpace --> childSpace1
    parentSpace --> childSpace2
    childSpace2 --> grandchildSpace

Propagation is always on. It does not depend on the resource inheritance toggle, and it does not stop at spaces that have inheritance disabled. Turning inheritance off between two spaces changes resource sharing and upward read, but a role bound higher in the tree still cascades straight through.

Root space caution

The root space is the parent of every other space, so a binding on root propagates to your entire account. Grant roles on root only when you mean "everywhere".

Resource inheritance (read up the tree)

Resource inheritance is a per-space toggle (Enable inheritance when you create or edit a space). When a space inherits from its parent, any stack in that space can use the parent's attachable resources: worker pools, contexts, policies, cloud integrations, and so on. Inheritance chains, so a space also inherits from its grandparent if every link in the chain has inheritance enabled.

Inheritance also has an access consequence. So that a principal can actually see the parent resources their space inherits, anyone with any access to an inheriting space automatically gets Read on the parent.

Only Read climbs up, never Write or Admin. A Space Admin on a child does not become admin of the parent; they become a reader of it. The read stops at the parent it climbs to and does not spread sideways to the parent's other children.

A user across a small tree

A user is granted, through login policies or Identity Access Management:

• Write on a services space that inherits from root.
• Admin on a platform space with inheritance disabled.

Because services inherits, the user also receives Read on root, letting them see the shared resources services pulls from it. On the platform side, inheritance is off, so no read climbs up. The Admin role still propagates down into platform's children as usual.

Implicit stack access

Stacks get two grants that no one assigns explicitly. Both exist so a stack can function without you hand-wiring read access it needs.

Self-read on its own space

Every stack can always read the space it lives in, even when it holds no binding there. Without this, a stack whose only role bindings target other spaces would have no access to its own home space.

Like any other grant, the self-read propagates down, so a stack can also read every space beneath its home space.

This grant is implicit: there is no role binding behind it, so it cannot be removed. In the UI it appears the same as any other resident read on the space.

Read up to inheriting parents

Resource inheritance also gives stacks upward Read. A stack residing in (or bound to) a space that inherits from its parent gains Read on that parent, folded down to the Space reader role no matter how broad the stack's own role is. This is the grant the Space Details view labels Inherited from child space, shown only on the Stacks tab.

graph TD
    root[root]
    parent[parent]
    child["child (inheritance enabled)"]
    stack(("stack"))

    root --> parent
    parent --> child
    stack -. resides in / self-read .-> child
    stack -. implicit Read .-> parent

A stack that both lives in a space and holds a custom binding there can therefore show up with more than one grant on a parent: its self-read and its inheritance-driven read are separate things, even when both render as Space reader.

Reading the Space Details view

Open a space and its detail view lists everything that can act in it, split into tabs for Stacks, Users, IdP Groups, and API Keys. The Stacks tab needs only read access to the space; the Users, IdP Groups, and API Keys tabs require admin on it. Two columns tell you where each grant comes from:

• Role: the effective role. System roles carry a SYSTEM badge. For access that climbed up through inheritance, this shows Space reader, because Read is all that propagates upward.
• Granted via: the space (or group) the grant actually originates from, with an icon and tooltip describing the relationship.

The Stacks tab has an Include all stacks toggle for showing stacks that have access to this space but reside elsewhere. Off, you see only stacks that reside in the space. On, you also see stacks that reach the space by propagation or inheritance (this requires admin access to the space).

What the "Granted via" labels mean

Label	Icon	Meaning
Current space	space	Resident: the role is bound directly to this space. The implicit stack self-read also appears this way.
Inherited from parent space	↓	Access propagation: the role is bound on an ancestor and cascades down to this space.
Inherited from child space	↑	Resource inheritance: a stack in an inheriting descendant gains Read up here.
Granted via group	group	The user holds the role through an IdP group they belong to.

A note on the labels

The view uses the word "Inherited" for the downward Inherited from parent space case, but that access is propagation, not resource inheritance. The two are different mechanisms (propagation is always on; inheritance is a toggle). Read Inherited from parent space as "propagated from an ancestor".

The implicit stack self-read is not shown as anything distinct: it appears as an ordinary Current space grant.

Related topics

• Access control: roles, permission matrix, and authorization methods for spaces.
• RBAC system: roles, actions, and the built-in access levels (Read, Write, Admin).
• Stack role bindings: how stacks receive roles, cross-space access, and external state access.