Skip to main content

Groups and access

CortexHub starts from least privilege: by default, an agent can do nothing. Capability is granted deliberately, and every action is governed in two stages.

  1. Entitlement decides what an agent may even attempt. Before any rule about approval or redaction is considered, CortexHub asks a simpler question: is this toolkit granted to a group the member belongs to? If not, the tool is invisible to the agent and the action stops there. Groups are the only tool gate.
  2. Policy decides how a granted attempt is handled. Once a tool is entitled, CortexHub resolves the layered policy for that call into a single decision plus any obligations.

Groups vs members​

ConceptScopePurpose
MemberOrganisationA person who belongs to the organisation
Governance groupOrganisationA subset of members with toolkit and tool entitlements plus access rules

Every member joins an auto-created default group named All staff when they join. Admins create additional role-shaped groups (for example "Finance" or "Support") and assign members. A member can belong to several groups at once, and their effective reach is the union of every group they belong to.

Toolkit and tool entitlements​

For each group, an admin:

  1. Publishes toolkit access through the publish flow (Overview, Auth, OAuth scopes when applicable, Policies, then review and publish).
  2. Configures allowed auth methods (the subset of connect methods the toolkit supports).
  3. For OAuth toolkits, selects which OAuth scopes members in the group may request. Platform defaults are pre-selected and required scopes are always included; members see only the admin's selection at connect.
  4. On Policies, first chooses which tools members can use, then sets the governance decision per safety profile (with optional per-tool overrides).

Unpublished drafts grant nothing. Adding a toolkit to the organisation catalogue does not expose it to anyone until it is published to a group. The All staff group does not auto-grant vendor toolkits.

Safety profiles and safe defaults​

Every tool is classified the moment it becomes available by what it does and how reversible it is. The main dimension is the safety profile:

  • Read: retrieves information without changing anything. Permitted by default.
  • Write: creates or changes data. Permitted by default.
  • Destructive: deletes data or causes changes that are hard to undo. Requires approval by default.

The highest-risk categories (moving money, irreversible destruction, and exporting regulated data) are held at "require approval" by a built-in safety floor that no admin or member can drop below.

The three layers: organisation floor, group, member​

Rules are set in three layers, and each lower layer can only tighten the layer above it, never loosen it.

  1. Organisation floor. The organisation-wide minimum every group and member inherits. Admins author it in plain language (for example, "any action that exports customer data needs approval") and can apply curated compliance packs as ready-made bundles. Admins see a readback of the effective floor.
  2. Group. Each group can tighten policy for the toolkits it reaches, per safety profile and per tool. Authored by admins and applied to everyone in the group.
  3. Member. A member can govern their own connected toolkits and their own personal files, and can further tighten any organisation toolkit they reach through a group. Members use the same controls admins use, scoped to themselves.

The decision, and what wins​

At call time, every applicable policy (the floor, the relevant groups, and the member's own policies) is resolved into a single base decision plus any obligations:

  • Base decision (the gate): permit, require approval, or deny.
  • Obligations layered on top: the call can also store a redacted record (sensitive fields withheld from the stored copy, never from the live action) and require re-authentication before it runs.

When layers disagree, the strictest gate wins, and obligations from every layer are combined rather than cancelling each other out. If nothing matches a call, it is denied. So a single call can be "permitted, but re-authenticate, and store a redacted record."

This tighten-only guarantee is enforced both when a rule is written (looser options are not offered, and the screen explains which layer set the binding limit) and again when the call actually runs, so the written rules and the runtime behaviour can never disagree.

What members can and cannot do​

A member governs only what is theirs, and only in the tightening direction:

  • They can set the base gate (permit, require approval, or deny) on their own connected toolkits, per safety profile and per tool, and on their own personal files.
  • They can disable a tool for themselves entirely.
  • They can never loosen below the organisation floor or their group's rules, never re-enable a tool an admin disabled, and never weaken the organisation's oversight of approvals.
  • Obligations (redaction and re-authentication) and the risk reclassification of a tool are admin-only; members see those as read-only, marked as set by an admin.
  • Personal files carry a built-in protection: deleting a file requires approval by default. A member can make that stricter but not weaker.

Approvals​

When a decision is "require approval":

  • The invoke is parked and returns awaiting_operator_approval or awaiting_user_consent, creating a task the agent polls until it resolves.
  • Back office: a designated operator decides at the routed destination. The default is the built-in operator review queue (acted on from the Approvals page); admins can also route to a chat channel or a webhook. Organisation back-office oversight always takes precedence, so a member can never route around it.
  • End user: interactive runs show a consent card in the moment; unattended runs notify the responsible person on their verified personal channels.

An approval is used exactly once, the approved action resumes on its own, and it runs once and only once.

See also​