If we want parents to be accountable, then these platforms need to provide better tools to enable parents to do so. It is impossible to monitor the entirety of your child's behavior online through any of these platforms today. They are their own person, they make their own choices, and those choices are heavily influenced by a world the parents have increasingly less influence over, especially as they grow older.
On the flip side, I do think we should also hold companies more accountable for this. We collectively prevented companies from advertising tobacco to minors through regulation with a pretty massive success rate. These companies know how harmful social media can be on youth, and there is little to no effective regulation around how children learn about these platforms and get enticed into them.
There are infinite things worth doing, a machines ability to actually know what's worth doing in any given scenario is likely on par with a human's. What's "Worth doing" is subjective, everything comes down to situational context. Machines cannot escape the same ambiguity as humans. If context is constant, then I would assume overlapping performance on a pretty standard distribution between humans and machines.
Machines lower the marginal cost of performing a cognitive task for humans, it can be extremely useful and high leverage to off load certain decisions to machines. I think it's reasonable to ask a machine to decide when machine context is higher and outcome is de-risked.
Human leverage of AGI comes down to good judgement, but that too is not uniformly applied.
I think this particular exploit crosses multiple trust boundaries, between the LLM, the MCP server, and Supabase. You will need protection at each point in that chain, not just the LLM prompt itself. The LLM could be protected with prompt injection guardrails, the MCP server should be properly scoped with the correct authn/authz credentials for the user/session of the current LLMs context, and the permissions there-in should be reflected in the user account issuing those keys from Supabase. These protections would significantly reduce the surface area of this type of attack, and there are plenty of examples of these measures being put in place in production systems.
The documentation from Supabase lists development environment examples for connecting MCP servers to AI Coding assistants. I would never allow that same MCP server to be connected to production environment without the above security measures in place, but it's likely fine for development environment with dummy data. It's not clear to me that Supabase was implying any production use cases with their MCP support, so I'm not sure I agree with the severity of this security concern.
I don’t think the real divide is “doom tomorrow” vs “nothing to worry about.” The crux is a pretty straightforward philosophical question "what does it even mean to generalize intelligence and agency", how much can scaling laws tell us about that?
The back-and-forth over σ²’s and growth exponents feels like theatrics that bury the actual debate.
The article skims over the details from the FCC, in this situation Twilio is guilty by association. They are the CPaaS provider for a company called PhoneBurner, which in-turn provides services to a Mortgage company (MV realty) who is the primary offender of the robocalls.
The FCC is taking a firmer stand and threatening those that support robocalls all the way down the chain. All CPaaS providers need to do a better job managing their customer vetting processes.