Shared AI sessions make a ton of sense.
We already do a janky version of this today.
I talk through something with ChatGPT, copy the useful parts to a friend, and they keep going from there.
Or I share the conversation.
Or two people work through the same problem together.
Nothing weird about that.
Until the chat has tools.
Now give that shared session MCP
Say two developers are working in the same Claude session.
Both have Google Drive connected.
Maybe GitHub too.
Maybe HubSpot.
AWS.
Whatever.
Now we have a problem.
Most MCP authentication today is built around one person.
I connect Google Drive. OAuth happens. The agent can access my Drive.
Perfectly reasonable when I'm the only person using the session.
Now add User B.
User A has their Google Drive connection.
User B has theirs.
User B says:
Find that document User A was looking at and copy it into my Drive.
Which credential gets used?
If the answer is "the agent figures it out," you've already lost.
The model is not your security boundary
This is the part I think we need to be way more aggressive about.
Do not give a shared agent a pile of user credentials and expect the prompt to enforce permissions.
That's not security.
That's asking nicely.
If everyone is intentionally using the same shared resource, this is easy enough.
Use a service account.
Use an API key.
Give that MCP connection exactly the permissions the team needs.
Now the shared session has a shared identity.
Great.
But a lot of services don't work that cleanly.
Google Drive is tied to users.
HubSpot may be tied to users.
Facebook definitely gets weird.
Sometimes OAuth is the only realistic authentication model.
So now what?
Every tool call needs an actor
I think this is the piece most shared-agent designs are missing.
Don't attach the credential to the chat session.
Attach authorization to who caused the tool call to happen.
Every person in the conversation already has an identity.
Use it.
User A sends a message.
That message carries User A's identity through the agent runtime.
The agent decides it needs Google Drive.
The request hits an MCP gateway.
The gateway sees that User A initiated the request and exposes only the MCP connections User A is allowed to use.
User B sends the next message?
Same conversation.
Same context.
Different authorization.
That should be non-negotiable.
Here's the weird part
User A says:
Find my architecture document for project X.
The agent calls Google Drive using User A's authorization.
It finds the document.
The shared session now knows that document exists.
Then User B says:
Cool, copy that file somewhere I can download it.
The model understands exactly which file User B means.
That's good.
That's the whole reason shared context is useful.
But User B did not suddenly gain permission to User A's Google Drive.
Their request hits the gateway.
Their identity doesn't unlock User A's connection.
The tool call gets blocked.
Shared context does not need to mean shared authorization.
Those are completely different things.
We should stop designing systems like they're the same.
And yes, there is an obvious hole
User A can still say:
Print the entire document into the chat.
If the agent does that, congratulations, the document is now in the shared conversation.
User B can read it.
The gateway can't put the toothpaste back in the tube.
But that's a different security decision.
User A authorized bringing that information into shared context.
What we're preventing is User B independently reaching back through User A's credentials and pulling whatever they want.
There are probably additional controls you'd want.
Maybe sensitive tools can't dump full documents into shared sessions.
Maybe some tool output is only visible to the requesting user.
Maybe content gets classified before it enters shared context.
There are a lot of nasty edge cases here.
But none of that changes the basic rule:
The model should not get to decide whether a user is authorized.
Put MCP behind a gate
I think MCP gets much more useful once you stop treating the connection itself as something the agent owns.
Put a gateway or proxy in front of it.
The agent asks for a tool.
The gateway decides whether the request is allowed.
Who initiated it?
Which connection can that person use?
Which tools are allowed?
Which resources can that connection access?
Is this tool even allowed inside this shared session?
Only after those questions get answered should anything hit the actual MCP server.
That also gives you somewhere sane to put:
- audit logs
- rate limits
- approvals
- credential rotation
- policy
- resource scoping
Stuff we already know how to do.
We're just strangely willing to forget all of it once an LLM is involved.
Shared sessions get a lot more useful after this
Once auth lives outside the agent, things get interesting.
A team could share one GitHub service account.
User A could have a private Google Drive connection.
User B could have a private HubSpot connection.
Everyone can still work inside the same conversation.
The agent gets the shared reasoning context without getting universal access to every connected system.
That's a pretty important distinction.
The session owns context.
The user owns identity.
The gateway owns authorization.
Don't collapse those into one blob.
That's how you end up with a shared AI session that is one clever prompt away from becoming an internal data exfiltration tool.
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.
The more MCP moves from demos into real infrastructure, the less comfortable I am with agents holding credentials directly.
Give the agent tools.
Give the infrastructure credentials.
And never let "we share a chat" quietly become "we share access to everything."
Let me know what you think.
Top comments (1)
공유된 문맥과 공유된 권한을 분리한다는 마지막 구분이 핵심이네요. 여기에 승인 대기 중 사용자가 바뀌거나 작업이 재시도되는 경우도 포함하면 좋겠습니다. 최초 요청자와 실제 실행 시점의 권한을 함께 확인해야, A가 시작한 작업을 B가 이어받았다는 이유만으로 A의 연결이 계속 사용되는 일을 막을 수 있겠습니다.