DEV Community: elliot hutchins

Let's Share Sessions. And MCP.

elliot hutchins — Fri, 04 Sep 2026 04:36:31 +0000

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.

Why Are Your AI Automations Still Running on Your Laptop?

elliot hutchins — Mon, 24 Aug 2026 23:46:14 +0000

You wouldn’t run your SaaS off your laptop.

So why are we doing it with AI?

A lot of the AI automation I see right now still depends on a person sitting in the middle moving information around.

Production throws an error. Someone checks AWS logs, drops them into Claude, figures out what happened and creates a Jira ticket.

Another dev picks up the ticket and has an agent make the change.

Someone reviews it. QA tests it. Maybe DevOps has Codex check the deployment logs over MCP.

Information comes in. A decision gets made. Something happens.

Pretty simple.

Except we keep using humans to connect each step.

We are basically expensive middleware

Most of these systems already have APIs.

AWS knows an error happened.

GitHub knows what changed.

Jira knows what needs to be done.

CI knows whether the tests passed.

The agent can read the code.

So why does someone still need to copy the error out of CloudWatch, explain it to an agent, copy that answer into Jira, then have someone else feed Jira back into another agent?

We’ve automated the tasks without really automating the workflow.

That’s the part I think is going to change.

Where do you actually need a human?

This is probably the harder question.

And every team is going to have a different answer.

Some changes should absolutely require approval. Some companies have compliance requirements. Sometimes the agent is just wrong.

AI output is still pretty meh in plenty of cases.

But it’s getting harder to argue that a human needs to be involved in every step.

For a lot of work, I think you really need one or two human decisions.

Did we understand what we are trying to do?

And later:

Did we actually do it?

Everything between those two questions is fair game.

Even the second one gets interesting when the intent is specific enough.

If the requirement says this endpoint needs to return X, these tests need to pass, latency can't increase past Y and this error should stop appearing in the logs... a machine can check most of that.

Probably better than someone clicking around dev for ten minutes.

Take a boring production bug

Say a service starts throwing a new error.

That error could kick off a job automatically.

Pull the surrounding logs.

Check what deployed recently.

Look through the relevant code.

Figure out the likely cause.

Create a Jira ticket with the useful context already attached.

Then pick that work up, create the branch, make the change, add the test and open the PR.

Deploy it to dev.

Run the E2E tests.

Check the logs.

See if the original problem is still happening.

Nobody has needed to do anything yet.

Maybe that's where a developer gets involved.

They get the issue, the change, the test results and what happened after deployment.

Approve it or don't.

If you want to be more conservative, put a person at the beginning too. Let them approve the diagnosis before spending tokens and changing code.

If you want to hit the gas, make merge approval the checkpoint.

The exact line isn't really the point.

The interesting part is how much work happens before you need that line at all.

The part we're missing is memory

We already have good agents.

Claude Code can work through a codebase.

Codex can work through a codebase.

MCP gives them access to other systems.

The piece I keep coming back to is what happens when one agent is done.

Where does everything it learned go?

Right now the answer is often a chat window.

Or a terminal.

Or Jira after a developer manually summarizes it.

That's not great.

The error, logs, investigation, decisions, code changes, test results and deployment results should live somewhere the next step can use them.

A database would honestly solve a surprising amount of this.

Call it state, context, memory, whatever.

Just stop making a person carry it around.

This is a lot of what I've been thinking about while setting up my automations on SchemaBounce. I started out thinking about where agents do work. Increasingly I think the more interesting problem is the infrastructure that lets them keep doing work without needing somebody to babysit every transition.

Which gets me back to the laptop

You can build almost all of this locally today.

A couple MCP servers, Claude Code or Codex, some AWS access, GitHub, Jira and a little glue code.

I've done versions of it. A lot of developers have.

But eventually you end up with a pretty funny architecture:

Your laptop has become production infrastructure.

Close the lid and your automation is gone.

VPN drops? Gone.

Token expires? Gone.

Someone else wants to use it? Have fun recreating your setup.

Want to know exactly why an agent made a decision three weeks ago? Hopefully you kept the terminal open.

Once these things are actually doing parts of the SDLC, they probably need the same boring stuff we expect from everything else we run.

Hosted somewhere stable.

Scoped credentials.

Persistent state.

Logs.

Retries.

Timeouts.

Versioned workflows.

An audit trail.

Observability.

Not because any of that is exciting.

Because the goal shouldn't be to build the world's coolest prompt running on a MacBook.

The interesting version is when an error can happen at 2 AM, the system can investigate it, put together a fix, prove what it tested, and have something useful waiting for a developer in the morning.

No copy/paste required.