How we hacked YC Spring 2025 batch’s AI agents — Rene Brandel, Casco

A security analysis of YC AI agents reveals that the most critical vulnerabilities are not in the LLM itself, but in the surrounding infrastructure. This breakdown of a red teaming exercise, where 7 out of 16 agents were compromised, highlights three common and severe security flaws: cross-user data access (IDOR), remote code execution via insecure sandboxes, and server-side request forgery (SSRF).

July 30, 2025 4 min read

How we hacked YC Spring 2025 batch’s AI agents — Rene Brandel, Casco — source: https://www.youtube.com/watch?v=kv-QAuKWllQ

The security posture of AI systems requires looking at the entire system, not just the Large Language Model (LLM). While discussions often center on prompt injection or harmful content generation, the most significant risks emerge from the interaction between the LLM, its tools, and the downstream infrastructure. A red teaming exercise on 16 publicly-accessible YC AI agents revealed that 7 could be compromised within 30 minutes each, not by attacking the model’s reasoning but by exploiting fundamental application security flaws.

Three common, high-severity issues were identified:

1. Cross-User Data Access via IDOR

A primary vector for data leakage was Insecure Direct Object Reference (IDOR). Agents were often granted broad permissions, failing to authorize if the authenticated user had the right to access a specific piece of data.

The Exploit: After leaking a system prompt that revealed tools for looking up user and document information by ID, attackers found a user ID in a public demo video’s URL. By simply inputting this ID, they accessed that user’s private information. This initial breach was transitive; the user object contained chat IDs and document IDs, allowing the attackers to traverse and access a wide range of data across the system.
The Root Cause: The core mistake is treating the AI agent like a trusted internal service rather than an entity acting on behalf of a potentially malicious user. Developers who would not typically build a web app this way seem to pattern-match the agent as a “server” and grant it service-level permissions.
The Fix: Implement a two-step process for every request: authentication (is the token valid?) and authorization (does this specific user have permission to access this specific resource?). This can be enforced using mechanisms like role-level security (RLS), ensuring the agent operates strictly within the permissions of the user it represents.

2. Remote Code Execution via Insecure Sandboxes

Many agents leverage tools that generate and execute code on demand. If not properly isolated, this functionality becomes a gateway for total system compromise.

The Exploit: An agent was discovered to have a code execution tool with seemingly innocent permissions: writing a Python file and reading files. The attackers first used the read permission to map the file system, discovering an app.py file that contained all the security logic for the code execution environment. They then used the write permission to overwrite app.py with an empty file, effectively disabling all protections.
Lateral Movement: With arbitrary code execution achieved, attackers performed service metadata discovery from within the container. They found the cloud service token, which unfortunately had overly permissive scopes, granting them access to query the company’s entire customer database in BigQuery.
The Fix: Do not build your own code sandbox. It is an incredibly difficult security challenge. Use battle-tested, third-party sandboxing solutions (e.g., E2B) that are designed for multi-tenancy and proper isolation using technologies like Firecracker, not just Docker containers. As the speaker warns, “if you just use containers, by the way, that’s not an isolation layer”.

3. Server-Side Request Forgery (SSRF)

SSRF vulnerabilities arise when an agent can be tricked into making an arbitrary request to an unintended endpoint from the server-side, often carrying sensitive credentials with it.

The Exploit: An agent’s tool allowed it to create a database by pulling a schema from a private GitHub repository. The tool accepted the repository’s URL as a string input. Attackers simply provided a URL to a malicious server they controlled. The system, attempting to authenticate to what it thought was a private repository, sent its Git credentials directly to the attacker’s server.
The Result: With the captured credentials, the attackers could clone the company’s entire private source code.
The Fix: Rigorously sanitize all inputs and outputs. Never blindly trust a URL or any other input from the user or the LLM to make a server-side request. All destinations should be validated against a strict allow-list.

Key Takeaways for Building Secure Agents

Agent Security is System Security: Focus beyond the LLM. The most critical vulnerabilities lie in the connections between your API server, tools, and data sources.
Treat Agents as Users: An agent should inherit the permissions and trust level of the user it serves, not elevated service-level permissions. Apply the same sanitization and security principles as you would for any user-facing application.
Don’t Roll Your Own Security Primitives: Especially for complex functions like code execution, rely on specialized, hardened solutions. An “intern project turns into a nightmare very quickly”.