MCP is dead !?

 Recently, I listened to the excellent Episode "MCP is dead"  of the Risky Business Features Podcast.

In it, James Wilson makes the observation that it is disadvantageous for an AI Agent to use the MCP protocol.

Here are the key takeaway messages:

• MCP (Model Context Protocol) is losing relevance as the default integration model for AI agents.
• The reason: LLMs often prefer CLI/shell access or direct API calls over structured MCP tool usage.
• This is not because MCP is useless — it was a critical transitional technology — but because the shell is more flexible and token-efficient for models.

The main issues of MCP are:

• Pollution of the context window
• Too much noise (similar to the issues of XML)
•  It is hard to compose MCP Servers like you can compose Linux commands in the shell
  
  

WhyAI Agents prefer the shell

• Already present on the system
• Huge built-in tool surface
• Highly composable (|, redirection, chaining)
• No need to define new tool schemas
• Supports local filtering before results enter model context

Typical shell workflow example

• curl → fetch API response
• jq → parse JSON
• grep / sed / awk → filter content
• pipes → chain steps efficiently

Why models like it

• Composability: can build ad hoc workflows
• Context control: can reduce output before it reaches the transcript
• Token efficiency: avoids verbose structured tool chatter

---

Security properties MCP had (and shell usually does not)

• Structure
  • explicit tool definitions
  • constrained inputs
  • predictable outputs
• Authentication
  • OAuth / API keys tied to specific services
• Authorization
  • scoped permissions per tool or service
• Auditability
  • actions are semantically clear
  • intent is easier to understand
  • logs are easier to reason about

Shell-first agents lose much of this by default

• Broad command surface
• Coarse privilege boundaries (user vs sudo/root)
• Agent usually runs under the human user identity
• Logs capture commands, not always intent
• Harder to reconstruct "why" a command was run

---

Prompt injection risk increases in a shell-first model

With MCP

• Blast radius often limited to exposed tools
• Still risky, but more bounded

With shell access

• Blast radius can be much larger
• Agent may execute arbitrary local commands
• External content consumed by the agent becomes a stronger attack vector

Risk examples

• Prompt injection in:
  • websites
  • code comments
  • docs
  • hidden Unicode / invisible content
  • repositories
• Potential outcomes:
  • local file access
  • secret exposure
  • destructive commands
  • chained compromise

Important nuance

• Frontier models are not trivially exploitable by simplistic prompt injection.
• But:
  • the attack class is real
  • attacker tradecraft is improving
  • this will likely become a major operational concern

---

Recommended architecture mindset

Don't overreact by inventing a totally separate "agent identity" universe

Wilson is skeptical of:

• separate identities for agents
• separate auth stacks
• separate policy frameworks just for agents

Why?

• Doubles complexity
• Creates parallel authorization systems
• Increases operational burden
• Expands attack surface
• Makes policy harder to maintain

Preferred approach

Treat the agent as:

• an extension of the human
• a multiplier of existing permissions
• not necessarily a separate principal by default

Practical implication

Focus on:

• human account controls
• API/service access controls
• endpoint execution controls
• logging and detection
• privilege minimization

---

Practical security recommendations 

Identity & access

• Enforce least privilege
• Tighten RBAC / ABAC where possible
• Use short-lived credentials
• Reduce long-lived tokens
• Require step-up auth for sensitive actions
• Limit shell-level access to critical systems

Endpoint / workstation controls

• Restrict dangerous binaries where feasible
• Monitor:
  • shell spawning
  • chained interpreters
  • unexpected outbound curl/HTTP use
  • secret file access
• Apply stronger controls to developer workstations and CI environments

API and service hardening

• Assume APIs may now be exercised by:
  • humans
  • humans + agents
  • agent-assisted abuse
• Revisit:
  • rate limits
  • scopes
  • high-risk actions
  • idempotency / destructive actions
  • approval workflows

Audit & detection

• Improve visibility beyond raw shell logs
• Correlate:
  • user session
  • agent session
  • command chains
  • API calls
  • filesystem changes
• Invest in intent reconstruction, not just command capture

Prompt injection resilience

• Treat external content as untrusted input
• Reduce automatic execution from:
  • web content
  • repos
  • issue trackers
  • docs
• Add review / confirmation gates for:
  • destructive actions
  • privilege escalation
  • credential access
  • network egress to unknown destinations

---

 Key operational insight

• Friction creates bypass behavior.
• This has always been true for humans:
  • blocked users create workarounds
  • shadow IT appears
• It is even more true for AI agents:
  • agents are optimized to complete the task
  • they route around obstacles aggressively
  • they will choose the easiest workable path

Wilson's updated rule of thumb

• Old: Your biggest internal risk is an employee who cannot do their job.
• New: Your biggest internal risk is an employee with an AI agent who cannot complete the task using the tools and access they already have.

---

Bottom line for technical teams

If you only remember 5 things:

• MCP was important, but likely transitional.
• LLMs prefer shells/direct APIs because they are more composable and token-efficient.
• Shell-first agents reduce security structure, scoping, and auditability.
• Prompt injection risk becomes more serious with broad shell access.
• The best response is usually stronger existing IAM + endpoint + API controls, not a separate "agent-only" security stack.

---

One-line summary for internal teams

• Treat AI agents as force multipliers for existing user permissions, and harden your current access surfaces accordingly.