Agentic AI use cases are evolving rapidly. At IIW, we mapped four MCP use cases that show how identity and authorization must adapt. This post shares the highlights and emerging challenges from that discussion.
At the recently concluded IIW “unconference”, my session titled “The four use-cases of MCP (with distinct identity properties)” drew tremendous interest. It shows how much everyone cares about getting identity in MCP—and the broader AI technology landscape—right. In this blog, I summarize the discussion, so the ideas are not mine; they are a distillation of the collective output of that session. A special thanks to all who attended and shared their thoughts.
As seen in the picture above, the four use-cases are:
The interactive use case is similar to a user accessing enterprise data through their browser. User consent and interaction can proceed as in a normal web interaction use case. The MCP protocol has an “Elicitation” feature to support this kind of interaction.
Here, the user and the organization the user works for need to place a higher level of trust in the agent, because the user may specify a task at a high level, and the agent may think of multiple subtasks to achieve the higher-level task.
The example we considered in the session is: “The user wants to buy tickets for a certain concert. They initiate the task and (go to bed / go to the beach /
In most cases, this would be preposterous, but in the case that the user was actually trying to get rid of their old car, this strategy might make sense. How does one determine if the “sell the car” task is within the charter of the “buy concert tickets” task? If the system is implemented using the Enterprise Managed Authorization extension of MCP, will the authorization server issue an access token with the “sell car” scope for the car buying service when the agent attempts to obtain it?
The trust in the agent therefore becomes critical in this case. If the agent has to wait for the user to return, then this use case becomes the same as the interactive use case.
The autonomous use case is similar to the delegated use case, except that the charter of the agent in the autonomous use case is durable. In the Delegated use case, each task is a different charter for the agent to act on, whereas in the autonomous use case, the charter is determined when the agent is deployed. For example, in the Delegated use case, the agent may have a charter “buy concert tickets” in one instance, but a few days later, the charter might be “create a streaming schedule of movies to watch with my spouse over the fall”. Whereas in the Autonomous use case, the charter will always be something like “assign yourself the next available customer service ticket that relates to our company’s product X, and work to solve it”.
Similar to the delegated use case, one will have to trust the agent for the specific application it is employed for.
There is another difference in that the agent permissions no longer have a specific human principal tied to them. They are their own principal. The access management system will have to treat such agents with specific non-human identities (NHIs) and describe access policies in relation to them.
The chained use case is similar to the first three use cases as applicable. However, for the chained use case to work, a mechanism must be in place to preserve the originating identity (human or non-human) and the identities of the agents in between in order for an access decision to be made at a downstream MCP server.
We only scratched the surface of the access management concerns in these use cases at the IIW session. I’m excited to be working on solutions for these use cases. I would love to talk to you if you have thoughts or questions about all this. Feel free to reach out to me.
Want more of the latest identity-first security topics and trends delivered to your inbox? Helpful and insightful content, no fluff.