11–20 of 73 posts
> In traditional security, we think in terms of isolated components. In the AI era, context is everything. In traditional security, everyone knows that attaching a code runner to a source of untrusted input is a terrible idea. AI plays no role in this. > That’s exactly why we’re building MCP Security at Pynt, to help teams identify dangerous trust-capability combinations, and to mitigate the risks before they lead to…
There is lorem ipsum text when viewed on mobile.
> In traditional security, we think in terms of isolated components. In the AI era, context is everything. In traditional security, everyone knows that attaching a code runner to a source of untrusted input is a terrible idea. AI plays no role in this. > That’s exactly why we’re building MCP Security at Pynt, to help teams identify dangerous trust-capability combinations, and to mitigate the risks before they lead to…
These types of vulnerabilities have been known for a long time, and the only way to deal with them is locking down the MCP server and/or manually approving requests (the default behavior)
> In traditional security, we think in terms of isolated components. In the AI era, context is everything. In traditional security, everyone knows that attaching a code runner to a source of untrusted input is a terrible idea. AI plays no role in this. > That’s exactly why we’re building MCP Security at Pynt, to help teams identify dangerous trust-capability combinations, and to mitigate the risks before they lead to…
It’s not a great blog post. He attached a shell MCP server to Claude Desktop and is surprised that output / instructions from one MCP server can cause it to interact with the shell server. These types of vulnerabilities have been known for a long time, and the only way to deal with them is locking down the MCP server and/or manually approving requests (the default behavior)
[0] https://windowsforum.com/threads/echoleak-cve-2025-32711-cri...
"Prompt injection" is way more scary than "SQL injection"; the latter will just f.up your database, exfiltrate user lists, etc so it's "just" a single disaster - you will rarely get RCE and pivot to an APT. This is thanks to strong isolation: we use dedicated DB servers, set up ACLs. Managed DBs like RDS can be trivially nuked, recreated from a backup, etc.
What's the story with isolating agents? Sandboxing techniques vary with each OS, and provide vastly different capabilities. You also need proper outgoing firewall rules for anything that is accessing the network. So I've been trying to research that, and as far as I can tell, it's just YOLO. Correct me if I'm wrong.
You must never feed user input into a combined instruction and data stream. If the instructions and data can't be separated, that's a broken system and you need to limit its privileges to only the privileges of the user supplying the input.
Installing malware on your own computer with extra steps?
Have you read the article? The source of the attack is an inbound email received in the logged in user's mailbox and read by the logged in user's Claude Desktop app.
> In traditional security, we think in terms of isolated components. In the AI era, context is everything. In traditional security, everyone knows that attaching a code runner to a source of untrusted input is a terrible idea. AI plays no role in this. > That’s exactly why we’re building MCP Security at Pynt, to help teams identify dangerous trust-capability combinations, and to mitigate the risks before they lead to…
OMG!
Devs are used to taking shortcuts and adding vulnerabilities because the chance of abuse seems so remote, but LLMs are external services typically, and you wouldn’t poke a hole a give ssh access to someone you don’t know externally, nor would you advertise internally in your company that an employee could query or delete data randomly if they so chose, so why not at the very least think defensively when writing code? I’ve gotten so lax recently and have let a lot of things slide, but I’m sure to at least speak up when I see these things, just as a reminder.