NVIDIA shipped its agent switch on. Ship yours off.
NVIDIA App users opened their settings and found agent control already switched on after an update. If your product is getting an MCP server, where that switch sits on day one is a trust decision.
If you add an MCP server or other agent connection to your app, leave it off for existing users after an update and ask at the first real connection, naming the agent and what it can do. Split read access from actions, log agent activity, and give admins a fleet-wide off switch.
Somebody found the switch already on
On Thursday afternoon, PC gamers started opening their NVIDIA App settings and finding a toggle they'd never touched. It said "Allow Agents to control NVIDIA App," and, according to a widely shared PSA and other users confirming it, it was already switched on after an automatic update. That one post had been liked more than 17,000 times by Friday morning.
The feature itself is real and documented. NVIDIA's release notes for version 11.0.9.565 say the app now includes a local MCP server, the Model Context Protocol that lets AI assistants plug into software. A compatible agent can see your installed games, apply settings, and turn on ShadowPlay recording, all from a chat. The notes point to Settings > Features > AI Agents and App Connections. They don't say the switch starts on. Users found that part out themselves.
If you make software, this is worth ten minutes this morning. Adding an agent connection to your product is quickly becoming a normal thing to ship. The question is what position the switch is in when your users first see it.
The honest case for shipping it on
The people defending NVIDIA aren't wrong about the mechanics, so start there.
An MCP server on its own does nothing. Something still has to connect to it, and most people have no agent installed. The server listens on the local machine, not the open internet. The documentation for one agent plugin describes connecting over loopback and says nothing leaves the machine. And features that sit behind a setting nobody opens tend to go unused, which makes the launch look like a flop.
There's also a fair product argument. If every new capability ships off, the people who would love it never find it. Defaults are how most users experience a product, and "on" is how you find out whether anyone wants the thing.
All of that is reasonable. It's also the reasoning behind almost every default that later turned into a support thread.
Users don't judge a default by its threat model. They judge it by how they found out.
Why it still reads as a broken promise
Here's what the case for "on" leaves out. Users don't judge a default by its threat model. They judge it by how they found out.
"I opened settings and it was already on" is a discovery story, and it lands badly every time. It doesn't matter much that the server was local. What people heard was that an app they installed for drivers had quietly given software they've never met permission to act on their machine. One reply under the PSA made the trust point exactly: if you don't trust the checkbox when it's on, why would you trust it when it's off?
The work-device angle makes it sharper. A lot of these machines belong to studios, schools, and companies with their own rules about what can control what. An admin who learns about an agent permission from social media now has to audit every machine, and they'll remember who made them do it.
And "it does nothing until an agent connects" is precisely the problem. The day a user installs any agent for some other reason, that agent arrives with permission it never had to ask for.
Decision guide
Shipping the agent switch on vs off
| Consideration | On by default after update | Off, ask at first connection |
|---|---|---|
| Discovery | Users find it already on and post about it. | Users learn about it from the release note and a prompt. |
| First agent | Any agent installed later connects without asking. | The first connection names the agent and asks. |
| Work devices | Admins audit machines after the fact. | Admins choose a fleet policy before it matters. |
| Adoption | More machines have it on, fewer people chose it. | Fewer machines have it on, each one by choice. |
Our call: off on update, ask at first contact
If you're adding an agent connection to your app, ship it off for existing users, and make the first real connection the moment you ask.
That isn't the same as hiding it. Tell people it exists in the release notes and in the product. The difference is the order of events. Instead of "we turned it on, here's how to turn it off," the user hears "an agent wants to connect, here's what it would be able to do, allow or not." That asks at the exact moment the permission means something, from the person it belongs to.
New installs are a more honest judgment call. If agent control is a core reason people download your product, a clearly labeled choice during setup is fine. A silent change on update is not. The person who installed your app last year agreed to last year's app.
We've seen the merchant side of this already. Shopify's AI shopping channels enroll a store unless someone opens the Agentic settings page, and owners had to go looking for it. The same lesson applies from the other side of the counter.
What a good agent switch is made of
The toggle is the visible part. These are the pieces underneath that make "allow" a decision people can actually trust.
Split seeing from doing. Reading a list of installed games is not the same permission as launching one, changing settings, or starting a screen recording. Give read access and actions separate grants, and put anything that records the screen or writes files in its own tier.
Ask per agent, not once for all of them. "Allow agents" is a blanket. "Allow this assistant, from this publisher" is a decision. Show the agent's name when it first connects and let the user revoke that one later without turning the whole feature off.
Make the connection secret worth something. If any program that can read a file in the user's profile can pick up the connection token, the real gate is file access, not consent. Pair the token with the user's approval of that specific agent.
Show what agents did. A short activity list in settings that says which agent did what, and when. Our note on standing grants in a signed-in browser makes the same point: a permission you can't review is one you've stopped thinking about.
Respect admin policy. Give IT a way to lock the feature off across a fleet, and have it hold through updates.
How the work moves
A first agent connection, done right
- Agent knocks
A local agent tries to connect; the feature has been off since the update.
- Name it
Show which agent, from which publisher, is asking.
- Scope it
Offer read-only first; actions and recording are separate grants.
- Record it
Every action lands in a plain activity list in settings.
- Revoke it
Remove one agent without turning off the feature; admin policy overrides all.
Put this into practice
If you have an agent connection shipped or on your roadmap, run through these with whoever owns the release:
- On upgrade, what position is the switch in for someone who has never seen it? If it's on, change that before the next release.
- What does the user see the first time an agent actually connects? If the answer is nothing, that's the screen to design next.
- Can a user tell which agent did what last week, without opening a log file?
- Could an admin turn this off for every machine in one place and trust it to stay off?
- Does the release note say plainly what the default is?
None of this slows a launch down much. It decides whether your launch thread is people trying the feature or people posting where to find the off switch.
Designing agent access into a product is part of what we do in AI applications and agents, and the settings, consent screens, and activity views are ordinary web application work done carefully. If you're about to ship an MCP server and want a second opinion on the defaults, talk to us.
Related work: Spin:Market (agents).
We build alongside the people doing the work.
Bring us the problem you’re thinking about.