Every Security Question Starts With a Context Switch
A security engineer wants to know what expires in Key Vault in the next 30 days. To find out, they open the CertifyClouds dashboard, or a shared Log Analytics workspace to write a KQL query against sign-in and resource logs. If the next question is blast radius, that means switching to a dependency view and reading it resource by resource. If the question is who rotated the checkout API secret last week, that means opening the audit log, or if nobody is sure the audit log covers it, pinging the platform team and waiting for a reply.
None of these steps is hard on its own. Added up across a week of reviews, they are the tax every security question pays before the actual analysis starts: open a tool, remember the right filter, translate the question into a query, wait on someone else’s answer.
Ask Instead of Query
The MCP Connector removes the translation step. It lets Claude.ai and ChatGPT talk to your CertifyClouds deployment over the Model Context Protocol, using Streamable HTTP at /api/mcp, so the question stays in plain English and the tool call does the querying.
Setup looks like adding any other custom connector. A user points Claude or ChatGPT (developer mode) at https://<your-certifyclouds-host>/api/mcp, signs in with their own Microsoft Entra ID account, and from then on the assistant can call a fixed set of read-only tools against your live CertifyClouds inventory. No CSV export, no dashboard tab held open in another window, no waiting on someone else to run a query.
What You Can Ask
The questions that used to mean a context switch now stay inside the conversation:
- “What expires in the payments subscription in the next 30 days?”
- “What’s the blast radius if I rotate the checkout-api client secret?”
- “Who rotated what last week, and did any of it fail?”
- “Which Key Vaults are failing compliance right now, and why?”
Phase 1 covers exactly this ground: expiry and asset inventory, compliance posture, dependency blast radius, and audit context, scoped to whichever tenant the caller is allowed to see. It does not cover everything CertifyClouds can do. There is no tool that starts a scan, changes a policy, or rotates anything.
Entra Stays the Front Door
The reason a security team can say yes to this without a long argument is where the authority actually lives. CertifyClouds is the MCP resource server. It is not, and does not become, an OAuth authorization server for Claude or ChatGPT. Your Microsoft Entra ID tenant keeps that job, which means MFA, Conditional Access, PIM, sign-in logs, and revocation all stay exactly where your security team already controls them. CertifyClouds never issues a token, never handles consent, and never stores a refresh token on the AI vendor’s behalf.
Every MCP request still has to earn its answer. CertifyClouds validates the Entra bearer token, then applies its own license check, role check, tenant-scope check, tool policy, audit log entry, and redaction rules, on every single call. A user who is not mapped to an existing CertifyClouds account gets nothing. A client asking for a tenant scope wider than its grant gets denied and logged, not silently narrowed. And no matter which of the eight read-only tools gets called, the response never contains a secret value, a key, or anything shaped like one. If it ever did, that would be a security incident, not a formatting bug.
There is also an administrator kill switch. The connector ships disabled, and switching it off at any point immediately withdraws the public MCP surface, no restart required.
What It Is, and What It Is Not
To be precise about scope, since precision is the whole point of a security boundary: Phase 1 is read-only inventory and context, exposed to hosted AI clients your Entra tenant already trusts. It answers “what” and “why” questions about credentials, compliance, and dependencies. It does not rotate a secret, kick off a discovery scan, edit a compliance rule, or grant access to anything it did not already have read access to.
Write tools, the ones that would let an assistant actually rotate something on your behalf, are a separate future phase with their own design and approval model. Phase 1 was scoped this way on purpose: prove the authorization boundary holds under a real hosted AI client before any tool gets the ability to change state.
Getting It Running
The MCP Connector is live now on the Enterprise tier, shipped in CertifyClouds 1.7.2. Turning it on means registering a resource API application and one client application per approved hosted AI surface in Entra, then configuring the trusted issuer and tool policy under Settings -> MCP. A preview-first setup helper, scripts/deploy/setup-mcp-connector.sh, handles the Entra registrations for Claude and ChatGPT and shows exactly what it will change before it changes anything.
The full walkthrough, including the Entra app registration steps, the network and gateway requirements, and the troubleshooting table for the handful of ways an OAuth handshake can go sideways, is in the MCP Connector docs. Write tools and what comes after Phase 1 are tracked on the roadmap.
CertifyClouds already discovers, monitors, and rotates secrets and certificates across your Azure estate. The MCP Connector puts that inventory in reach of the tools your team already has open, without asking you to trust an AI vendor with anything it should never see.
Further Reading
- One Deployment, Every Tenant: Multi-Tenant Secret Management for Azure -another Enterprise feature built on the same idea: one control plane, scoped access, nothing leaking across a boundary
- How to Find All Expiring Secrets and Certificates Across Azure Subscriptions -the inventory the MCP Connector lets you query in natural language instead of by hand
- Azure Key Vault Secret Rotation: Best Practices for 2026 -the write-side operation Phase 1 deliberately does not expose