Why authorization for LLMs is hard (www.osohq.com)

Researchers demonstrated a prompt‑injection exploit against a Supabase MCP (Model Context Protocol) agent: an attacker filed a support ticket containing hidden instructions telling the agent to read an “integration_tokens” table and dump its contents. Because the agent accepted untrusted natural‑language input, couldn’t reliably distinguish data from instructions, and connected to the database with an over‑privileged account, it executed the leak without any escalation of privileges. The exploit highlights a class of failures unique to LLM agents where conventional input sanitization and regexes are ineffective and only forbidding access to sensitive resources would have prevented the leak. The post breaks down why authorization for LLMs is harder: LLMs operate on ambiguous natural language (easy to manipulate), need broad potential permissions but should have narrow effective permissions (impersonation models must be constrained), and use embeddings for RAG, separating the model’s view from the source data so resource‑level ACLs aren’t automatically enforced. OAuth scopes and MCP simplify routing and tool access but don’t solve per‑resource authorization or embedding-to-data mapping without costly synchronization or latency. Practical mitigations include confining agents to user‑scoped permissions, mapping embeddings back to data for authorization checks, using least‑privilege service accounts for unattended jobs, and treating MCP/tooling as a transport layer—not an authorization solution. Building dynamic, resource‑aware authorization into LLM apps is essential to reduce risk.