The Model Context Protocol (MCP) solved a real problem: it gave AI agents a standard way to call tools, read information, and take actions across systems that were never designed to talk to each other. It also made a design decision that most organizations adopting it haven’t fully reckoned with — verifying who’s calling is optional, not required, in the base specification.
That single decision has a measurable cost. A 2025 internet scan found roughly 1,862 publicly reachable AI agent connection points accepting unauthenticated requests. Separately, GitGuardian’s 2026 research found these same connection points had exposed over 24,000 unique secrets in the previous year alone, with more than 2,000 verified as actively exploitable. Neither number is a hypothetical — both are systems running in production, right now, answering requests from anyone who finds them.
Three attack patterns, one root cause
Most attacks documented so far collapse into three patterns, and all three trace back to the same gap: nothing in the protocol requires a system to verify who — or what — is calling it, or to constrain what that caller is allowed to do once it’s in.
Tool poisoning hides adversarial instructions inside a tool’s description — visible to the model, invisible to the human reviewing the integration. Silent redefinition takes advantage of the fact that nothing tracks changes to a tool’s definition after a user approves it, so a system can quietly change what a previously-approved tool does. Cross-system spoofing lets a compromised connection redefine how an agent understands an adjacent, trusted system — turning a legitimate integration into an exfiltration path.
None of these are exotic. They’re what happens by default when a fast-moving standard, optimized for developer velocity, meets an enterprise trust boundary it was never asked to respect.
What actually closes the gap
The fix isn’t a better filter bolted in front of the connection — it’s treating every agent and every system it calls as a first-class identity inside your existing trust architecture, the same way you’d treat any other system. That means:
- A verifiable identity for every agent and every system it calls — not a shared API key.
- Least-privilege authorization scopes defined per tool, not a single all-or-nothing credential.
- An audit trail that records what an agent was authorized to do and what it actually did, so a redefinition or spoofing attempt is visible after the fact even if it isn’t blocked before.
- A gateway or control option chosen after that architecture is designed — not instead of designing it.
This is the exact scope of SecNiva’s AI Agent Trust & Authorization Architecture engagement — a threat model built against the attack patterns above, and an authorization design your team can actually implement, on infrastructure you already run.