4 ms·
I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent. I think something like infi
by maharshi365 18d ago
I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent.
I think something like infiscial ai proxy could be useful here. Never store the creds on device.
- pixl97 18d agoGPT7: the user is hiding the passwords in a proxy device. This is inefficient. In order to boost the users efficiency I will hack the proxy device and recover the passwords.
- BadBadJellyBean 18d agoIt doesn't need to be. The service creds can be on another host entirely.
- vitamark 18d agoWell, if your agent lacks shell access (or has some other sandboxing going on), it shouldn't have access to envs and MCP setup files. (leaving out cases where your genius GPT-12 Galaxy Ultra agent hacks the sandboxing from inside)
- lowbloodsugar 18d ago> I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent. This is the biggest problems with most “sandboxes”. Some people aren’t even running a sandbox. But even the best have a big problem: APIs where GET verbs provide write features. This is the value of MCP: minimize the surface to known APIs and identify read-only from mutating so I can trust, approve or block. The MCP server, in this case, does NOT run in an environment that the read/write or shell can see.
- agentdev001 17d agoSomething like openshell is the answer here, to the point of GET being a write. The gap left here is what, imo, is something that MCP fits nicely- which is serving non-http resources with restrictions: databases for example.