The attack? A malicious project file tricks the LLM into executing arbitrary shell commands.
The scary part? This isn't a Cursor bug. It's an architectural problem that exists in every AI agent that reads untrusted data and acts on it.
Here's why traditional security fails:
❌ API gateways can't see inside LLM reasoning
❌ WAFs can't regex-match intent
❌ IAM policies see valid credentials, not compromised intent
❌ LLM safety filters are bypassed by design in prompt injection
The "lethal trifecta":
- Access to sensitive data
- Ability to perform actions
- Exposure to untrusted inputs
Most production AI agents have all three right now.
At Enclavia (Enclavia Labs), we don't try to make the LLM "smarter." We insert a hardware-enforced boundary (AWS Nitro Enclaves) between the agent's decision and its execution.
Every action is evaluated inside a cryptographically isolated TEE. If it's malicious, it's blocked. If it's approved, you get an attestation document proving the evaluation ran untampered.
Not a log entry. Mathematical proof.
The policy is bound to the hardware. Even a rogue DevOps engineer can't tamper with it without changing the PCR0 hash — and then AWS KMS mathematically denies access.
We've built a sandbox where you can try to break our agent. Spoiler: the hardware won't let you.
👉 Try it: Enclavia Sandbox
We're also selecting 5 design partners for early access (3 months free, dedicated onboarding, co-marketing case study).
If you're building AI agents that touch sensitive data or critical systems, let's talk.
Enjoyed this deep dive? Let's stay connected!
I share more software engineering insights, projects, and experiments across these platforms:
- Connect with me on LinkedIn
- Follow me on X
- Enclavia Blog
