The Three Actors
Every Agent action involves three actors: the User who delegates, the Agent acting for them and the Connection accessed. This is the core model of Cakewalk Agent Access.
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.
💡 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:
The User opens an Agent and gives it a task.
The Agent decides which Connection it needs and issues a tool call.
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.
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 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: the proxy that sits between the Agent and the Connection
The Tool Call Lifecycle: what happens to a tool call as it passes through the three actors
Roles and Permissions: the two roles (Admin, employee) that operate this product
Last updated
Was this helpful?