{"slug": "let-s-share-sessions-and-mcp", "title": "Let's Share Sessions. And MCP.", "summary": "A developer argues that shared AI sessions with tools require per-user authorization rather than shared credentials, proposing an MCP gateway that ties tool calls to the identity of the user who initiated them. The post emphasizes that shared context does not imply shared authorization and that models should not enforce permissions.", "body_md": "Shared AI sessions make a ton of sense.\n\nWe already do a janky version of this today.\n\nI talk through something with ChatGPT, copy the useful parts to a friend, and they keep going from there.\n\nOr I share the conversation.\n\nOr two people work through the same problem together.\n\nNothing weird about that.\n\nUntil the chat has tools.\n\nSay two developers are working in the same Claude session.\n\nBoth have Google Drive connected.\n\nMaybe GitHub too.\n\nMaybe HubSpot.\n\nAWS.\n\nWhatever.\n\nNow we have a problem.\n\nMost MCP authentication today is built around one person.\n\nI connect Google Drive. OAuth happens. The agent can access my Drive.\n\nPerfectly reasonable when I'm the only person using the session.\n\nNow add User B.\n\nUser A has their Google Drive connection.\n\nUser B has theirs.\n\nUser B says:\n\nFind that document User A was looking at and copy it into my Drive.\n\nWhich credential gets used?\n\nIf the answer is \"the agent figures it out,\" you've already lost.\n\nThis is the part I think we need to be way more aggressive about.\n\n**Do not give a shared agent a pile of user credentials and expect the prompt to enforce permissions.**\n\nThat's not security.\n\nThat's asking nicely.\n\nIf everyone is intentionally using the same shared resource, this is easy enough.\n\nUse a service account.\n\nUse an API key.\n\nGive that MCP connection exactly the permissions the team needs.\n\nNow the shared session has a shared identity.\n\nGreat.\n\nBut a lot of services don't work that cleanly.\n\nGoogle Drive is tied to users.\n\nHubSpot may be tied to users.\n\nFacebook definitely gets weird.\n\nSometimes OAuth is the only realistic authentication model.\n\nSo now what?\n\nI think this is the piece most shared-agent designs are missing.\n\nDon't attach the credential to the chat session.\n\nAttach authorization to **who caused the tool call to happen**.\n\nEvery person in the conversation already has an identity.\n\nUse it.\n\nUser A sends a message.\n\nThat message carries User A's identity through the agent runtime.\n\nThe agent decides it needs Google Drive.\n\nThe request hits an MCP gateway.\n\nThe gateway sees that User A initiated the request and exposes only the MCP connections User A is allowed to use.\n\nUser B sends the next message?\n\nSame conversation.\n\nSame context.\n\nDifferent authorization.\n\nThat should be non-negotiable.\n\nUser A says:\n\nFind my architecture document for project X.\n\nThe agent calls Google Drive using User A's authorization.\n\nIt finds the document.\n\nThe shared session now knows that document exists.\n\nThen User B says:\n\nCool, copy that file somewhere I can download it.\n\nThe model understands exactly which file User B means.\n\nThat's good.\n\nThat's the whole reason shared context is useful.\n\nBut User B did not suddenly gain permission to User A's Google Drive.\n\nTheir request hits the gateway.\n\nTheir identity doesn't unlock User A's connection.\n\nThe tool call gets blocked.\n\n**Shared context does not need to mean shared authorization.**\n\nThose are completely different things.\n\nWe should stop designing systems like they're the same.\n\nUser A can still say:\n\nPrint the entire document into the chat.\n\nIf the agent does that, congratulations, the document is now in the shared conversation.\n\nUser B can read it.\n\nThe gateway can't put the toothpaste back in the tube.\n\nBut that's a different security decision.\n\nUser A authorized bringing that information into shared context.\n\nWhat we're preventing is User B independently reaching back through User A's credentials and pulling whatever they want.\n\nThere are probably additional controls you'd want.\n\nMaybe sensitive tools can't dump full documents into shared sessions.\n\nMaybe some tool output is only visible to the requesting user.\n\nMaybe content gets classified before it enters shared context.\n\nThere are a lot of nasty edge cases here.\n\nBut none of that changes the basic rule:\n\n**The model should not get to decide whether a user is authorized.**\n\nI think MCP gets much more useful once you stop treating the connection itself as something the agent owns.\n\nPut a gateway or proxy in front of it.\n\nThe agent asks for a tool.\n\nThe gateway decides whether the request is allowed.\n\nWho initiated it?\n\nWhich connection can that person use?\n\nWhich tools are allowed?\n\nWhich resources can that connection access?\n\nIs this tool even allowed inside this shared session?\n\nOnly after those questions get answered should anything hit the actual MCP server.\n\nThat also gives you somewhere sane to put:\n\nStuff we already know how to do.\n\nWe're just strangely willing to forget all of it once an LLM is involved.\n\nOnce auth lives outside the agent, things get interesting.\n\nA team could share one GitHub service account.\n\nUser A could have a private Google Drive connection.\n\nUser B could have a private HubSpot connection.\n\nEveryone can still work inside the same conversation.\n\nThe agent gets the shared reasoning context without getting universal access to every connected system.\n\nThat's a pretty important distinction.\n\nThe session owns context.\n\nThe user owns identity.\n\nThe gateway owns authorization.\n\nDon't collapse those into one blob.\n\nThat's how you end up with a shared AI session that is one clever prompt away from becoming an internal data exfiltration tool.\n\n**Shameless plug:** this is one of the workflows I'm working through with **SchemaBounce**. A lot of the design is built around keeping agent context, identity, MCP connections and authorization separate instead of letting one session become God Mode.\n\nThe more MCP moves from demos into real infrastructure, the less comfortable I am with agents holding credentials directly.\n\nGive the agent tools.\n\nGive the infrastructure credentials.\n\nAnd never let \"we share a chat\" quietly become \"we share access to everything.\"\n\nLet me know what you think.", "url": "https://wpnews.pro/news/let-s-share-sessions-and-mcp", "canonical_source": "https://dev.to/elliot_hutchins_13af77186/lets-share-sessions-and-mcp-4lfc", "published_at": "2026-09-04 04:36:31+00:00", "updated_at": "2026-09-04 04:54:05.797210+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools"], "entities": ["MCP", "Google Drive", "HubSpot", "AWS", "Claude", "ChatGPT"], "alternates": {"html": "https://wpnews.pro/news/let-s-share-sessions-and-mcp", "markdown": "https://wpnews.pro/news/let-s-share-sessions-and-mcp.md", "text": "https://wpnews.pro/news/let-s-share-sessions-and-mcp.txt", "jsonld": "https://wpnews.pro/news/let-s-share-sessions-and-mcp.jsonld"}}