I spent some time this weekend reading the new Model Context Protocol roadmap.
At first glance, it is not exactly thrilling material.
Messaging primitives. HTTP transport. Identity. Better primitives. SDK experience.
But the more I read it, the less I thought about the protocol itself.
What caught my attention was what MCP is slowly becoming.
The first wave of MCP was about connecting models to tools. Give an agent access to Slack, GitHub, Salesforce, a database, an internal API. Make the connections easier and give developers a common way to expose capabilities.
That was the easy part.
The harder question starts once the connections exist:
What is the agent actually allowed to do?
And then the questions multiply.
Who is this agent?
Who gave it authority?
Is it acting for a human, another agent, or itself?
If it creates a sub-agent, how much authority should that sub-agent inherit?
Can it delegate again?
What tools was it able to discover?
And if something goes wrong, can I reconstruct the chain of decisions and actions afterwards?
This is why I think the MCP roadmap matters from a security perspective.
MCP is moving from being a tool-calling protocol toward becoming part of the runtime boundary of the agentic enterprise.
And runtime boundaries are where security markets get built.
The protocol can standardize the wire. It can’t standardize trust.
This is the idea I keep coming back to.
MCP can standardize the wire. It does not automatically give us the trust layer above it.
The roadmap itself makes that increasingly visible.
One of its biggest priorities is agent identity and enterprise security.
MCP authorization largely grew out of a world where a person is present, approves access and authenticates through a browser.
That model starts to break when the caller is a cloud workload.
Or an agent running for six hours.
Or an agent acting on behalf of a user who is no longer present.
Or an agent that creates three other agents to perform parts of a task.
The roadmap is moving toward much better foundations: DPoP, Workload Identity Federation, token exchange, Enterprise-Managed Authorization and work around agent identity.
That is important.
It is also only the beginning.
Because identifying a machine is not the same thing as deciding what that machine should be trusted to do.
I think “agent identity” is too broad a category
There are already plenty of companies around workload identity, machine identity and authorization.
So I don’t think the opportunity is simply, “we need identity for agents.”
The more interesting problem is delegated authority across agent chains.
Imagine this:
A person asks Agent A to investigate a customer issue.
Agent A creates Agent B to pull data from Salesforce.
Agent B invokes Tool C.
Tool C accesses System D using an enterprise credential.
Now try answering a few basic security questions.
Was Agent B actually authorized?
Did it receive all of Agent A’s permissions, or only the permissions required for this task?
Can B create Agent C?
When does that delegated authority disappear?
What happens if the user revokes the original request?
Can I revoke one branch of the delegation tree without killing the whole workflow?
And three days later, can the SOC reconstruct exactly who — or what — caused an action?
Those are not edge cases. They are what happens when autonomous software begins acting instead of just answering questions.
The standards are starting to provide some of the building blocks.
The products still need to be built.
The awkward part: the security debt already exists
There is another reason I think the timing matters.
We are improving the protocol while insecure implementations are already being deployed.
The Cloud Security Alliance documented more than 30 MCP-related CVEs disclosed between January and March 2026, with command injection representing a significant share of them.
Researchers at Wiz also found MCP servers exposed directly to the internet, including deployments with weak or missing authentication and credentials embedded behind them.
That is an uncomfortable gap.
A better identity model in the next version of the specification does nothing to repair an MCP server somebody deployed six months ago with a long-lived API key.
Security standards usually improve faster than enterprise estates migrate.
That migration gap is often where security companies get built.
I don’t know that the answer is exactly a three-year or five-year cycle. But I would be surprised if enterprise MCP environments suddenly became clean, authenticated and policy-controlled because the standard got better.
This is almost certainly a multi-year problem.
Progressive discovery is more interesting than it looks
One part of the roadmap I think deserves much more attention is progressive tool discovery.
Today, connecting an agent to a server with hundreds of tools is inefficient. The model has to see or reason over a huge catalog even if the user only needs one capability.
Progressive discovery tries to fix that by revealing tools as the conversation or task narrows.
Makes sense.
But the moment discovery logic determines which capabilities an agent can see, discovery becomes part of the security boundary.
Think about the benign failure first.
A customer asks for a refund.
The discovery layer interprets the conversation as general account support and never reveals the refund capability.
The agent can technically perform the action, but never discovers that it exists.
Now think about the adversarial version.
If I can manipulate the context that drives discovery, perhaps I can influence which capabilities appear.
That starts to look surprisingly similar to prompt injection.
Except instead of manipulating only what the model thinks, I am manipulating what the model is capable of doing.
I expect we will eventually need to monitor discovery itself:
What tools were available?
Why did they become available?
Did the catalog change?
Was a sensitive capability surfaced unexpectedly?
Was something hidden that should have been available?
That is a new security telemetry source almost nobody is monitoring today.
Authorization alone won’t be enough
There is also a layer I don’t think we talk about enough yet.
Suppose an agent is correctly authenticated.
Its identity is valid.
Its permissions are correct.
Every individual API call is authorized.
You can still have a security problem.
Imagine an agent with legitimate access to CRM and email.
Reading ten contacts is allowed.
Drafting an email is allowed.
Sending an email is allowed.
Now the agent:
reads 20,000 contacts,
identifies every CFO,
generates personalized messages,
and sends them externally.
Every individual action may satisfy the static authorization policy.
The sequence of actions is the problem.
That is why I think runtime behavioral enforcement could become a major category.
Not only:
Is this agent allowed to call this tool?
But:
Should this agent be allowed to perform this action, at this moment, given the task it was given and everything it has already done?
That starts to sit somewhere between IAM, policy engines, runtime security and detection.
I suspect some of the most interesting agent-security companies will be built in that gap.
Where I would look for companies today
If I had to rank the areas rather than put every MCP security opportunity into the same bucket, this is roughly how I see it.
Tier 1: Delegation and agent authorization
This is the area I would spend the most time on today.
Not generic machine identity.
The real question is how authority propagates through autonomous systems.
Agent-to-agent delegation, narrowing of privileges, token exchange, time-bounded access, revocation and attribution across an execution chain all look increasingly important.
There are already vendors approaching different parts of this market — Aembit, Britive, Ory, Scalekit, Silverfort, SecureAuth and others.
Natoma’s acquisition by Snowflake is also an interesting early signal of where large infrastructure platforms believe agent authorization may belong.
I wouldn’t treat one transaction as proof of a category.
But I would pay attention to it.
The startup opportunity is probably not rebuilding the traditional IdP for agents.
It is solving the parts of delegated machine authority that user-centric IAM architectures were never designed for.
Tier 1: Runtime enforcement
The second area I like is the enforcement point itself.
Enterprises are unlikely to want every individual MCP server implementing authorization, validation and security differently.
There needs to be somewhere policy can actually be enforced.
That could be an MCP-native gateway, an inline agent security layer, or something that eventually looks very different from today’s API gateway.
The valuable product will not simply proxy MCP traffic.
Proxying will commoditize.
The interesting version understands:
the identity of the agent,
the authority it inherited,
the user or workload behind it,
the tool being invoked,
the context of the task,
and potentially the sequence of actions that came before.
Then it can make an enforcement decision before the agent touches the underlying system.
That is much harder to absorb into a basic protocol implementation.
Tier 2: Agent observability and audit
I also think there is a real market forming around observability.
Long-running tasks, delegated execution, tool discovery and server-initiated events create telemetry most SOCs are not collecting today.
Existing logs may tell you which credential accessed a system.
They may not tell you:
which agent initiated the action,
which parent agent created it,
which human authority sat at the beginning of the chain,
what tools the agent had available,
what it attempted before succeeding,
or what the actual business outcome was.
That last point matters because protocol state and business state are not necessarily the same thing.
A task can be technically completed even if the underlying outcome is effectively a failure.
A dashboard that treats protocol completion as business success will produce some very reassuring green boxes while something is going badly wrong underneath.
There is room here for an agent-native audit trail and detection layer.
Think less “logging for MCP” and more the system of record for autonomous actions.
Tier 3: Discovery integrity and tool provenance
I think this category is earlier.
But I would watch it closely.
If tool catalogs become dynamic, enterprises will eventually care about provenance.
Who created this tool?
Who approved it?
Has its definition changed?
Was the tool the agent discovered today the same one security reviewed last month?
Can catalogs be signed?
Can drift be detected?
Can we prove which version of a tool definition an agent acted against?
There is a familiar software-supply-chain pattern emerging here, except the supply chain is made of capabilities exposed to autonomous systems.
Early, yes.
But interesting.
Tier 3: MCP conformance and assurance
There is also likely a market for continuous testing of MCP environments.
Does the server enforce scopes correctly?
Does it validate parameters?
Does it expose tools anonymously?
Does it handle cancellation safely?
Can malicious tool results influence downstream behavior?
Are credentials embedded somewhere they shouldn’t be?
This could look like a mix of posture management, protocol testing and penetration testing specialized for agent infrastructure.
Useful category.
Potentially good companies.
But I would be careful about how much of the value remains standalone as cloud platforms and security incumbents add MCP scanning themselves.
The companies I would worry about
This brings me to the other side of the investment thesis.
Every new protocol creates startups whose main product is fixing something the protocol itself hasn’t implemented yet.
Some will become great companies.
Others are temporary patches.
The MCP roadmap is therefore not only a list of opportunities.
For some founders, it is a list of expiration dates.
If your moat is:
“MCP doesn’t support X, so we provide X,”
and X appears directly on the protocol roadmap, I would be nervous.
The more durable companies will solve problems that exist because the ecosystem is distributed and autonomous, not because the current version of the specification happens to be incomplete.
Trust.
Delegation.
Enforcement.
Behavior.
Attribution.
Assurance.
Those problems don’t disappear when the protocol improves.
In some cases, the protocol getting better makes them more important.
That’s the part I find interesting
The first MCP wave helped models connect to things.
The second wave will have to decide what those models should be trusted to do once they are connected.
That’s a very different problem.
The roadmap talks about jobs that can outlive a request, callers that aren’t people, authority that needs to move between machines, and tool catalogs too large to expose blindly.
Those sound like protocol-design problems.
But underneath, almost every one of them is a security problem.
And that is why I think the next important MCP companies won’t necessarily be the companies building another connector or another developer wrapper.
They will be the companies answering a harder question:
When autonomous software can act across the enterprise, where does trust end and enforcement begin?
That’s the boundary I’m watching.
And if you’re building around delegated agent authority, runtime enforcement, agent observability or discovery integrity, I’d genuinely like to hear what you’re seeing.
Et voilá,
F.
Sources: MCP Development Roadmap; MCP roadmap announcement, David Soria Parra, August 22, 2026; Cloud Security Alliance - Agentic AI Autonomy Levels and Control Framework; Wiz research on exposed MCP servers; The Cyber Hut - Agentic Authorization cheat sheets