Access control and organization isolation

Use this page to see who can reach your organization's content in Vidext and what each person, and each AI assistant they connect, can do with it.

Vidext checks every action against both the thing being acted on and the role of the person acting. The checks run on the server; they do not rely on a button or page being hidden in the interface.

Organization isolationCopy Anchor Link

Customer content, knowledge, teams, learning records, and organization settings are scoped by an organization identifier. A person can belong to more than one organization, but each request runs in one selected organization context and must pass that organization's membership and permission checks.

Internal services process data to operate the product, as described in Data handling and AI providers and data flow. Organization isolation means one customer's role does not grant access to another customer's workspace; it does not mean the service has no authorized operational processors.

RolesCopy Anchor Link

Organization roles (admin, member, learner, and requester) govern workspace and content actions. Team roles (admin and learner) govern team management and learning assignment. The right to build and publish content comes from the organization role only; joining a team never grants it.

See Roles and permissions for the complete action matrix.

Two rules apply everywhere:

• A requester awaiting approval does not receive organization content access.
• A user must be an active organization member before a team role can grant learning access.

The chatCopy Anchor Link

Courses are built in the chat, where admins and members tell Vidext's agents what to teach. Vidext's agents are AI agents that research the material, plan the course, write each module and build it. Only organization admins and members can open the chat.

• Conversations are private to their participants. A conversation is visible to the person who started it and to up to 20 admins and members brought onto it: by the owner from Share, or by anyone on it who tags them in a message. Organization admins cannot open a conversation they were not added to. Only the owner removes people from a conversation, archives it, or deletes it.
• Access ends with the role. Leaving a conversation, being removed from it, being removed from the organization, or being changed to learner ends a person's access to it.
• Each conversation runs in isolation. The agents' work for a conversation runs in its own isolated cloud environment with no open internet access. It can read only its own organization's course files and storage, its model and research requests go through Vidext's services, and provider credentials are never placed inside it.

See Data handling for what a conversation stores and how long.

Who can publishCopy Anchor Link

What learners see changes only through these actions, each checked against the acting user's organization role:

• Organization admins and members can build modules, publish a course or an update of it, unpublish it, and withdraw or restore a module of a course.
• Only organization admins can archive, restore, or delete a course.
• Assigning teams to a course is open to organization admins and to admins of a team the course is already assigned to. A team admin role never grants building modules or publishing courses.
• Vidext's agents can build modules but never publish a course, and a connected AI assistant cannot publish either.

What learners seeCopy Anchor Link

Learners see live content only: the live modules of the published courses assigned to their teams. A published course with no live module is hidden from them. Any active organization member can also open an organization-only link to a live module someone shares with them. Learners do not reach the creator dashboard, the chat, or settings.

• Working drafts, built versions, and live versions of a module are stored separately. The places where admins and members build and edit use the draft; learner playback uses the module's live version, which only publishing its course sets.
• A module is live only while its course is published and the module is neither withdrawn nor archived; every action that hides it takes it out of learner playback at once.
• Archived content is excluded from learner and default active-content views.
• Reaching anonymous visitors requires a separate, explicit Public access choice in the module line's details, beside the studio. It is off by default, available only for a live module, revocable at any time, turned off whenever the module stops being live, hidden from search engines, and changeable only by organization admins and members.

See Enrollments for assignment behavior, Live is not public for public access, and Review, publishing, and traceability for how a generated version becomes learner-visible.

Connected AI assistantsCopy Anchor Link

An AI assistant connected over MCP acts as the person who connected it, in one organization, with that person's permissions:

• Admins and members only. Learners and requesters cannot connect an assistant.
• Read only. The assistant can search and read the organization's sources and check modules and their status. It cannot build, change, or publish anything.
• Checked on every call. The person's role is checked on each request, so removing them from the organization or changing them to learner cuts the assistant off.

An assistant connects through OAuth or through agent registration. See Identity, sessions, and connected assistants.