# The Three Actors Cakewalk governs the relationship between three actors. Once you can name them, every other concept in this chapter falls into place. *** ### 📖 Key Concepts * **User**: The human who delegates work to an Agent. * **Agent**: The AI client that acts on a User's behalf, such as Cursor, Claude Desktop, ChatGPT Desktop or Copilot. * **Connection**: The downstream app an Agent accesses through the MCP Gateway, such as GitHub, Jira, Linear or Slack. :bulb: *Why this matters:* Cakewalk does not govern Agents in isolation. It governs the User-Agent-Connection triple at every tool call. This is what makes "same Agent, different User" produce different outcomes. *** ### 🔁 How the Three Actors Interact Every Agent tool call flows along the same path: 1. The User opens an Agent and gives it a task. 2. The Agent decides which Connection it needs and issues a tool call. 3. The tool call passes through the MCP Gateway, which evaluates Policy against the full triple (action type, User attributes, Connection attributes) then produces one of three outcomes: Auto-approve, Require approval or Deny. 4. The Connection receives a request as if the User made it directly. The User is the trust anchor. The Agent inherits the User's access envelope. The Connection holds the data being protected. *** ### 👤 The User Users are synced from your company's HRIS or IdP. Cakewalk does not maintain a separate identity store for Agents. They act on behalf of the same User records you already manage. Each User's attributes (department, title, location, user category) are inputs to every Policy decision. Each User can have: * Multiple Connections (the third-party apps they have authorized) * Multiple Agents (the AI clients they have set up through the MCP Gateway) * Many sessions per Agent When a User is offboarded, every Agent acting on their behalf loses access at the next tool call. No standing permissions persist. *** ### 🤖 The Agent Agents are MCP clients. They are not a separate identity category: an Agent is an app that happens to act on behalf of a User through the MCP Gateway. An Agent appears in the **Agents** table once it is in your company's Agent catalog. It only shows as Active after a User has set it up through the MCP Gateway. See [Connection and Agent Statuses](/docs/ai-agent-access/concepts/connection-and-agent-statuses.md) for the full state model. Agents do not request access on their own account. Every tool call references the User who delegated. The Agent is transparent to the Policy engine: Policies evaluate the action type, the User and the Connection. They do not target specific Agents. *** ### 🔗 The Connection A Connection is one downstream MCP server. Connecting GitHub means authenticating once through Cakewalk and storing the credential in the vault. From that point on, any Agent acting on that User's behalf can access GitHub through the MCP Gateway, subject to Policy. Connections are governed at the app level. Cakewalk holds attributes for each Connection (category, risk level) that Policies match on. Resource-level enforcement (this specific GitHub repo, this specific Salesforce record) is the downstream app's responsibility: Cakewalk operates at the Connection and tool-call layer. *** ### Related Concepts * [The MCP Gateway](/docs/ai-agent-access/concepts/the-mcp-gateway.md): the proxy that sits between the Agent and the Connection * [The Tool Call Lifecycle](/docs/ai-agent-access/concepts/the-tool-call-lifecycle.md): what happens to a tool call as it passes through the three actors * [Roles and Permissions](/docs/ai-agent-access/concepts/roles-and-permissions.md): the two roles (Admin, employee) that operate this product --- # Agent Instructions: 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: ``` GET https://www.cakewalk.security/docs/ai-agent-access/concepts/the-three-actors.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.