Hi,
I’m looking at cipp-mcp because the tool surface has a real admin trust boundary: M365 user/admin actions, offboarding, MFA/session controls, mail forwarding, and tenant-level operations.
One question I’m exploring:
If a client approves a CIPP MCP tool in one state, should the runtime re-check trust if that tool’s scope or side effects change later?
Example drift cases:
- a read/list tool later gains disable/offboard behavior
- a narrow admin action later gains broader tenant scope
- mail-forwarding or session-revocation behavior appears under an already-approved surface
- tool schema/description stays similar, but the blast radius changes
To a static allowlist, this may still look like the same approved tool. But from the agent/user’s perspective, the capability changed.
How do you think this should be handled for a CIPP-style admin MCP server today? Is post-approval re-review expected to happen outside the server, or is that not part of the current threat model?
I’m asking because I’m building Interlock, an open-source MCP runtime trust layer focused on detecting this kind of post-approval tool drift before execution. Happy to run a small non-production drift check against the public CIPP MCP tool surface if useful, no tenant creds or customer data.
Maaz
https://getinterlock.dev
Hi,
I’m looking at cipp-mcp because the tool surface has a real admin trust boundary: M365 user/admin actions, offboarding, MFA/session controls, mail forwarding, and tenant-level operations.
One question I’m exploring:
If a client approves a CIPP MCP tool in one state, should the runtime re-check trust if that tool’s scope or side effects change later?
Example drift cases:
To a static allowlist, this may still look like the same approved tool. But from the agent/user’s perspective, the capability changed.
How do you think this should be handled for a CIPP-style admin MCP server today? Is post-approval re-review expected to happen outside the server, or is that not part of the current threat model?
I’m asking because I’m building Interlock, an open-source MCP runtime trust layer focused on detecting this kind of post-approval tool drift before execution. Happy to run a small non-production drift check against the public CIPP MCP tool surface if useful, no tenant creds or customer data.
Maaz
https://getinterlock.dev