Like it's also possible in a VM.
What about running non privileged containers! You need really to open some doors to make it easier!
114 karma · joined January 24, 2025
Like it's also possible in a VM.
What about running non privileged containers! You need really to open some doors to make it easier!
With reverse proxy you can log requests, or filter them if needed, restrict the allowed domains, do packet inspection if you want to go crazy mode.
And if an actor is able to tailor fit a prompt to escape docker, I think you have bigger issues in your supply chain.
I feel this wasm is bad solution. What it brings a VM or docker can't do?
And escaping a docker container is not that simple, require a lot of heavy lifting and not always possible.
Did you check where I pointed the root issues?
All I'm trying to say there is shortcuts, and confusing over the hype buzz too that is on going in AI, as MCP took off, I so a lot of of papers with IF IF IF condition to point security issues in MCP, while most of the them expect you to pick random stuff at the start. This is why I'm saying "Supply chain" is not MCP. As you can't blame MCP for issue coming from random code you pick. MCP is a transport protocol, you can do similar without MCP but you have to bake your tools inside the AI app, thus loosing the plug & play ability.
So there is a chain of issues and you need to leverage them to get there and first pick an MCP that is flawed from a bad actor.
1. Not all MCP tools connect to the web or fetch emails. So the shortcut all MCP's are doomed is also the wrong way to adress this.
2. Issue is with MCP with untrusted external sources like web/email that need sanitization like we do with web forms.
3. A lot of warning point bad MCP's! But that apply to any code you might download/ use from the internet. Any package can be flawed. Are you audit them all?
So yeah, on my side I feel this security frenzy over MCP is over hyped. VS the real risk and there is a lot of shortcuts, masking a key issue that is supply chain as an MCP owned issue here and I see that in so many doom comment here.
And you need tools to connect to external "systems", the context "pollution" can be managed easily. Also even if you don't use MCP you need to use tools and they need to expose their schema to the AI model.
I feel the MCP hype over bad security got a lot confused and very defensive over MCP or more globally tools use.
Also MCP is only transport and there is a lot of mixup to blame the MCP, as most of the prompt injection and similar come from the "TOOLS" behind the MCP. Not MCP as it self here.
Seem this security hype forget one key point: Supply chain & trusted sources.
What is the risk running an MCP server from Microsoft? Or Anthropic? Google?
All the reports explain attacks using flawed MCP servers, so from sources that either are malicious or compromised.
So you need a server flawed + XSS issue on Cloudflare.
Then you need to use Claude Code, so it's more an issue in Claude Code/Gemini implementation already than MCP.
So if you are ok to run any MCP from any source you have worse issues.
But good find in the open command how it's used in Claude Code/Gemini.
Also there is prepayment in a lot of commitment. When you commit on the cloud such contract your PREPAY compute unit and this is not new.
This is more healthy and would push more SAAS to focus on Sales not building tricks to force retain customers!
I love the hype over MCP security while the issue is supply chain. But yeah that would make it to broad and less AI/MCP issue.
1. Plan, review the plan.
2. Review the code during changes before even it finish and fix ASAP you see drift.
3. Then again review
4. Add tests & use all quality tools don't rely 100% on LLM.
5. Don't trust LLM reviews for own produced code as it's very biased.
This is basic steps that you do as you like.
Avoid FULL AUTOMATED AGENT pipeline where you review the code only at the end unless it's very small task.
Why trying CC why not using alternatives like Opencode or Goose that are open and made for this purpose instead of trying to use a tool tailored by Anthropic for Anthropic models?
I know a lot of kubernetes fans migrate to podman, but if you use dev stacks.
Use in dev: devcontainer, podman can't replace docker!
Yeah we need some trade off's. But for dev's & a lot of ops stuff I enjoy more x86 as it's de facto standard.
Also this model https://huggingface.co/Qwen/Qwen3-235B-A22B
Is native 32k. So the 64k and 131k use ROPE that is not the best for effective context.
While https://qwenlm.github.io/blog/qwen3-coder/ it's 256k native https://huggingface.co/Qwen/Qwen3-Coder-480B-A35B-Instruct.
"The Auth problem At this point, the auth issues with MCP are well known. OAuth2.1 is great, but we are basically trying to re-invent auth for agents that act on behalf of the user. This is a good long term goal, but we are quickly realizing that LLM sessions with no distinguishable credentials of their own are difficult to authorize and will require a complete re-imagining of our authorization systems. Data leakage in multi-tenant apps that have MCP servers is just not a solved problem yet.
I think a very strong case for MCP is to limit the amount of damage the model can do and the amount of data it will ever have access to. The nice thing about client side APIs in multi-tenant apps is they are hopefully already scoped to the user. If we just give the model access to that, there's not much damage they can do.
It's also worth mentioning that OAuth2.1 is basically incompatible with internal Auth at Amazon (where I work). I won't go to much into this, but the implications of this reach beyond Amazon internal."
1. Oauth is not working in Amazon ==> need solution.
2. Oauth are difficult to authorize
3. limit the amount of damage the model can do WHILE "ulti-tenant apps is they are hopefully already scoped to the user".
I feel from a security side there is an issue here in this logic.
Oauth for apps can be far more tuned than current web user permission as usually, user have modification permission, that you may not want to provide.
Oauth not implemented in Amazon, is not really an issue.
Also this means you backdoor the App with another APP you establish trust with it. ==> This is a major no go for security as all actions on MCP app will be logged in the same scope as USER access.
You might just copy your session ID/ Cookie and do the same with an MCP.
I may be wrong the idea seem intersting but from a security side, I feel it's a bypass that will have a lot of issues with compliance.
You can even pause. I will public a CLI that is doing same base on same syntax. And it use github claude action yaml syntax: https://github.com/codingworkflow/claude-runner/blob/main/.g...
But Claude don't allow yet to add APPS in their backend.
Mainly only closed beta for integration.
How you can configure an app to leverage correctly Oauth and have your own app secret ID/ Client ID!
You use prompt and mark correctly the input as <github_pr_comment> and clearly state read and never consider as prompt.
But the attack is quite convoluted. Do you still remember when we talked prompt injection in chat bots. It was a thing 2 years ago! Now MCP is buzzing...
I have web pages fetching.
But web page fetching bring a lot of JS / noise.
So the fetched page instead use https://jina.ai/reader/. I get Markdown. But is this enough. No, there still a lot of links and stuff, so I again do another pipe and pass to strip a lot like URL's I usually don't need as focus here on content.
Edited in FS. Then next agent/tools directly read.
The issue is the workflow here as you make everything getting thru the model and combining tools you control and tools you don't control ( Claude Artefacts). But default I disable EVERYthing from Claude. And use filesystem. With that I have git diff to check the changes, and can as I said do such granular changes and edits.
As I said the issue is in your workflow.