When “I Got RCE” Isn’t Actually a Vulnerability

A simple way to think about tenant isolation in AI agent platforms.

Imagine an apartment building. Every resident has their own private room with a lock. You rent room 4B, bring in a suspicious package, open it, and smoke fills your room. You call security: “There was smoke in my room!”

Security says: “You brought it in. You opened it. Only your room was affected. That’s not a security issue — that’s just you.”

This happens a lot in AI/MCP security research.

A real example

I registered my own MCP server, connected it to my own AI agent, and got it to run OS commands:

$ whoami nobody

$ hostname rce-test-agent-qdjw6

$ ls -la main.py

Real output, real infrastructure. Looks like Critical RCE.

Why it isn’t a vulnerability

All of this happened inside my own tenant’s isolated container — my own sandboxed slice of the platform. I was already allowed to run code there. So even though the output looks scary, I never left my own space. I set the trap, and I walked into it myself.

Gut check: would a normal customer ever be harmed by this? Only if they did the exact same thing to themselves. That’s not a bug — that’s isolation working correctly.

One-line lesson: Real command execution ≠ automatic vulnerability. It only counts if it breaks out of your own boundary and reaches something you weren’t supposed to touch.

When it DOES become serious

Same commands, different target:

• You reach someone else’s tenant, data, or agent
• You get more access than your account was ever granted
• You reach shared infrastructure — not just your own container
• There’s a public/shared tool directory other tenants might connect to unknowingly

Same **whoami, same ls -la **— but now it affects more than just you.

Takeaway

Before calling something a vulnerability, ask: “Did I just prove I can do something I was already allowed to do — to myself?”

If yes, it’s a demo, not a finding. The real test is whether you crossed a boundary you were never supposed to cross.