# Reference deployment progress + thoughts on where the real fit might be

[devopam]

Hi Maaz,

Thanks for naming mcpg as a reference deployment in the partner setup doc. We spent some time evaluating what a deeper integration would look like, and I wanted to share where we landed — including a piece we just shipped that signals direction of travel, and a concrete shape for what collaboration could look like next.

What we shipped first

mcpg PR #115 lands a pytest contract test that snapshots mcpg's entire tool surface — currently 173 tools, with each tool's name, description, and JSON-Schema input shape — and asserts equality against a checked-in JSON. Any accidental rename, removal, or schema widening fails CI before merge with a focused diagnosis (added / removed / changed tool names).

It's intentionally small — zero external dependencies, runs in our existing pytest job — and it covers the "accidental drift" case that motivated the CI-integration evaluation in the first place.

Why not Interlock-in-CI directly

Honest reading from the eval: the threat models didn't quite line up for the CI use case. Interlock is built to gate at runtime, where there's an approving agent on the other side of every call. In CI there's no agent — we'd be using Interlock as a snapshot comparator, which PR #115 does in ~80 lines without taking on a Docker dependency or coupling mcpg's release cadence to an external pre-1.0 project. That marginal cost felt hard to justify for the marginal "fancier diff output" benefit.

None of that is a comment on Interlock's runtime design point, which I think is solid — just that CI isn't where it shines.

Where I think the real fit might be

mcpg's existing access controls are DB-role-rooted: one PG role per server, plus an optional per-request X-MCPG-Role header that swaps it. What we deliberately don't ship is per-agent tool gating — e.g. "this Claude Desktop instance gets read tools A/B/C; that automation pipeline gets writes; the customer-support chatbot gets neither, ever, regardless of which DB role it presents."

That's identity-and-access-management territory, and we'd rather not grow mcpg into it. It's also exactly what an inline gateway like Interlock is built for.

A concrete shape this could take:

• Interlock sits between an MCP client and mcpg.
• It enforces a per-token tool allowlist that's strictly tighter than mcpg's startup gates (so even if MCPG_ACCESS_MODE=unrestricted, a given token can only call e.g. run_select and describe_table).
• It correlates its allow/deny log with mcpg's HMAC-chained audit (mcpg_audit.events) so any tool call that hits mcpg without a matching Interlock entry surfaces as an alarm — defense-in-depth that catches gateway bypass.
• mcpg becomes your first non-trivial reference deployment; Interlock fills a gap mcpg won't grow into. Mutual value, both projects gain something they can point to.

Asking nothing right now

This is a design conversation, not a partnership commitment from our side. Curious whether the per-agent gating shape resonates as a real concrete problem worth designing against, or whether you see a different shared problem that's a better starting point.

If the shape lands, the next useful step is probably a small co-design doc — what the per-token policy schema looks like, what mcpg would need to expose to make the audit correlation cheap, whether any of it requires structured tool annotations on our side or if today's surface is enough. Happy to draft that here once we're aligned on the problem.

Either way, congrats on the design-partner-stage release — looking forward to seeing where Interlock goes.

Best,
Devopam

[MaazAhmed47]

Hi Devopam,

Agreed on CI and you read it right. With no approving agent in the loop, Interlock would just be a snapshot comparator there, and PR #115 does that in 80 lines without the Docker/coupling cost. No argument from me; that's the correct call.

The per-agent gating shape resonates strongly it's a real, concrete problem. mcpg's DB-role gating answers "what can this role do," but not "what can this specific client do, regardless of the role it presents." That gap is exactly an inline gateway's job.

One thing I'd add from my side: the per-token allowlist gets stronger combined with the drift piece. It's not just "this token may call run_select", it's "this token may call run_select, and run_select's surface hasn't escalated since it was approved." Gate + verify-unchanged, together.

The audit correlation you described also fits naturally: Interlock allow/deny vs mcpg's HMAC chain, with any mcpg execution event lacking a matching Interlock decision treated as a possible gateway-bypass alarm.

Yes to the co-design doc. The pieces worth nailing down:

• per-token policy schema
• what mcpg exposes to make audit correlation cheap
• whether structured tool annotations are needed, or today's tool surface is enough
• what the smallest non-production reference deployment should prove

I can draft the first version in this discussion if that works. mcpg as the first real reference deployment works well for both sides.

Best,
Maaz