The authorization gap you're describing is real but I think there's a layer missing even before the gateway the MCP server itself. If the tool schema is compromised or the server is a trojanized fork (there's an active thread about this today), a gateway that enforces policy on tool calls is still trusting the server's self-reported tool definitions.
Provenance at the server level knowing the binary you're running was signed by the original author seems like a necessary complement to runtime authorization. Has Permit thought about integrating with any signing or attestation layer, or is the assumption that server integrity is out of scope?
Interesting approach. The context bloat problem is real I've been running into it while building an MCP server for a code knowledge graph. The pattern I landed on was the opposite direction: instead of compressing what goes in, keep the tool set small and well-scoped so the schema overhead stays predictable. Lazy tool loading helps too.
Curious how Packet28 handles the case where the agent genuinely needs historical context like when a bug in step 8 is caused by a decision made in step 2. Does the daemon store enough to reconstruct that, or does the handoff lose that thread?
This is a real problem and it's going to get worse as the MCP ecosystem grows. The supply chain trust issue is structurally identical to what npm faced in 2018-2020 and the stakes are higher because MCP servers have filesystem access by design.
The origin check approach you described is a good defensive measure, but it's ultimately opt-in and fragile. What the ecosystem actually needs is provenance signing at publish time so any client can verify that the binary they're running was signed by the same key as the original author, regardless of which marketplace or scope it came through.
Ed25519 signatures are 32 bytes and fast to verify. It's not a hard problem technically it's a coordination problem. Someone needs to establish the standard before the ecosystem gets big enough that bad actors have real incentive.
Provenance at the server level knowing the binary you're running was signed by the original author seems like a necessary complement to runtime authorization. Has Permit thought about integrating with any signing or attestation layer, or is the assumption that server integrity is out of scope?