MCP turns every tool into a trust decision.

MCP is becoming infrastructure for agent work. My focus is the security boundary around servers, tool descriptions, request identity, authorization and cross-tool execution.

The boundary I am trying to make explicit.

01

Can the caller be identified per request?

02

Are tools scoped to minimum capability?

03

Can one server influence another through the agent?

The findings become pre-execution checks, gateway policy and supply-chain controls.

VIEW THE WORK

Notes from this research thread.

MCP 2026-07-28 moves the security boundary to the server

The release candidate removes protocol sessions and makes requests easier to scale. It also leaves state integrity, authorization and resource controls squarely in each implementation.

MCP is making request identity explicit

MCP is moving authorization context from the connection to each request. The direction is clear; the stateless 2026-07-28 specification is still a release candidate.

Skills over MCP: who checks the manual?

SEP-2640 proposes discovering skills through MCP resources. The mechanics are promising; provenance, pinning, review, and instruction precedence remain open trust questions.

MCP as a supply chain: trust boundaries in agent tooling

Every server an agent calls is an implicit trust decision. How to make that decision explicit and find the remaining blind spots.

CONTACT

Tell me what you’re building.

Reach out about Oktsec, AI agent security, technical assessments, advisory or talks. I work with a small number of teams where the problem is concrete and the work can be useful.

OR EMAIL DIRECTLYgus@oktsec.com

I only use this information to reply. No lists, no sharing.