> For the complete documentation index, see [llms.txt](https://www.cakewalk.security/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.cakewalk.security/docs/concepts/what-cakewalk-governs.md). # What Cakewalk Governs Cakewalk governs five entities. Both modules operate on the same five; each module sees its own view of them. This page is the shared map. The detailed models live in each module's own docs, linked from every section. ### 📖 Key Concepts * **User**: a person, synced from your company's HRIS or IdP. One identity across both modules. * **Group**: a set of Users. Access arrives in bulk through the Apps a Group grants by default. * **App**: a SaaS application or service your company tracks and governs in Cakewalk. * **Agent**: an App with AI and MCP client capabilities that acts on a User's behalf. * **Connection**: an App an Agent can connect to and act on. :bulb: *Why this matters*: Human Access and Agent Access govern the same five entities from different angles. Knowing the map tells you which module answers which question. *** ### 🧑 Users A User is a person, imported from your company's HRIS or IdP with their department, job title, location and manager. The same User works in both modules: Human Access decides what the person holds, and Agent Access evaluates their Agents against the person's own attributes. Detailed model: [User Data Model in Human Access](https://www.cakewalk.security/docs/human-access/concepts/data-models). *** ### 👥 Groups A Group is a set of Users. Groups sync from your company's IdP or are managed in Cakewalk, and they are how access arrives in bulk: a Group can grant Apps by default, so a new member holds the right access without a single request. A Group that grants Agent Access by default is how whole teams get it on day one. Groups reach into Agent Access too: the team and department that Policies evaluate on every agent action come from the person's Groups. Detailed model: [Groups & RBAC in Human Access](https://www.cakewalk.security/docs/human-access/how-to-guides/users-and-groups/groups-and-role-based-access-control-rbac). *** ### 📦 Apps An App is a SaaS application or service your company tracks in Cakewalk. In Human Access, an App is what Users hold access to: granted, requested, reviewed, removed. The same vendor's app can also be what an Agent accesses. Slack can be a seat a person holds and, separately, an App their Agent posts to through a Connection. Detailed model: [App Data Model in Human Access](https://www.cakewalk.security/docs/human-access/concepts/data-models). *** ### 🤖 Agents An Agent is an App with AI and MCP client capabilities: it acts on a User's behalf and calls other Apps to get work done. Agents do not get identities of their own: an Agent acts for the person who delegated the task and never holds more access than that person. Agents live in Agent Access; the ones employees set up also appear in Human Access, so the directory stays complete. Detailed model: [The Three Actors in Agent Access](https://www.cakewalk.security/docs/ai-agent-access/concepts/the-three-actors). *** ### 🔗 Connections A Connection is an App an Agent can connect to and act on: the App exposes MCP server capabilities and Cakewalk governs every action that flows to it. Each User holds their own Connection per App, so an Agent always acts through the Connection of the person who delegated the task. The sign-in behind a Connection stays in Cakewalk's vault, never with the Agent. Detailed model: [The Three Actors in Agent Access](https://www.cakewalk.security/docs/ai-agent-access/concepts/the-three-actors). *** ### 📐 The App Hierarchy Every Agent and every Connection starts as an App. An App with AI and MCP client capabilities (it can act for a User and call other Apps) shows up in Agent Access as an Agent. An App with MCP server capabilities (it can be called by agents) is what a Connection links to. The same App can play both parts: run agents and be accessed by them. ![Agents and Connections are subsets of the Apps a User holds access to; the same App can be in both sets](/files/ujTdl6BagWBVgrurKrPe) *** ### 🕸 How They Fit Together The person is the thread. Groups gather people so access arrives in bulk. Apps hold their access. Agents act on their behalf. Connections carry each agent action to an App. Policies (the rules that decide each agent action) judge every action using the person's own attributes. ```mermaid %%{init: {"theme": "base", "themeVariables": {"primaryColor": "#F5F5F5", "primaryBorderColor": "#1E1E1E", "primaryTextColor": "#1E1E1E", "lineColor": "#8A8A8A"}}}%% flowchart LR HRIS["Your HRIS or IdP"] --> User["User"] HRIS --> Groups["Groups"] User -->|"belongs to"| Groups Groups -->|"grant Apps by default"| Apps["Apps"] User -->|"holds access to"| Apps User -->|"delegates work to"| Agents["Agents"] Agents -->|"every action"| Gateway["MCP Gateway"] Gateway -->|"Policies decide"| Connections["Connections"] Connections -->|"carry the action to"| Apps ``` *** ### 📚 Related * [Platform Overview](/docs/introduction/platform-overview.md) * [How They Connect](/docs/human-access-and-agent-access/how-human-access-and-agent-access-connect.md) * [Data Models in Human Access](https://www.cakewalk.security/docs/human-access/concepts/data-models) * [The Three Actors in Agent Access](https://www.cakewalk.security/docs/ai-agent-access/concepts/the-three-actors) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.cakewalk.security/docs/concepts/what-cakewalk-governs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.