The core shift in 2026 is a move from trusting the Model Context Protocol (MCP) infrastructure to scrutinising the MCP permission model that sits beneath it. Engineers who once relied on default installations now have to treat every credential and token as a potential attack surface, because over‑privileged permissions have proven to be the primary cause of recent breaches.
Why the Permission Layer Became the Weak Spot
Two high‑profile incidents illustrate the problem. In May 2025 a prompt‑injection attack against a GitHub‑hosted MCP server extracted private repository data; the server itself was not buggy, but the personal access token it used was scoped far beyond the task it performed. A later logic error in an Asana MCP integration let one tenant read another’s data because the permission layer never enforced tenant isolation. Researchers now categorise these failures as “tool poisoning” and the classic “confused deputy” problem, where an agent inherits more trust than its immediate job requires.
Designing a Permission‑First MCP Integration
Guidance from GitHub’s engineering team recommends three concrete steps:
- Provision a unique secret for each MCP instance that matches the exact task.
- Restrict every request to the identity of the acting user rather than assuming trust after authentication.
- Base authorisation on the specific action being performed, not on a blanket token.
The same advice stresses replacing static, long‑lived tokens with dynamically generated, short‑lived credentials. This approach limits the blast radius if a token is compromised and aligns with the principle of least privilege.
Operational Practices to Keep Permissions Tight
When integrating MCP, teams should run a checklist similar to the one used for other third‑party components:
- Identify the current reach of each credential versus its original intent; watch for scope creep.
- Prefer per‑site, per‑repository, or per‑workspace authorisation over organization‑wide access.
- Verify that the integration exposes a scope‑control UI at connection time; if not, treat the lack of control as a finding.
- Determine whether the AI agent inherits a human’s OAuth token or creates a fresh identity with its own permissions.
- Ensure logging captures the agent’s actions with the same accountability as a human operator.
- Route any changes the agent proposes through a review pipeline (draft, branch, approval) rather than applying them directly to production.
These practices translate the existing human‑centric access‑control discipline to the emerging class of autonomous agents.
Identity Before Access
Most organisations currently treat an AI agent as “a human’s OAuth token wearing a trenchcoat.” The agent lacks a distinct identity, inheriting the creator’s scope and credentials. This model works while agents run for minutes, but as agents begin to persist for weeks or months, the borrowed identity becomes a liability. A long‑lived agent needs its own identity with permissions that tighten over time, not a permanent badge that mirrors the creator’s full access.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
Practitioners must audit every MCP deployment for over‑privileged tokens, replace static secrets with short‑lived credentials, and enforce action‑based authorisation. Logging and review processes should treat agents with the same rigor as human users. As agents’ lifespans increase, design a dedicated identity for each agent and progressively restrict its permissions. Ignoring these steps leaves the permission layer as the most exploitable component of the MCP stack.
