The question bank examiners taught me to ask first
Bank examiners changed how I review technology. They wanted to see a control working for a particular customer on a particular day. An architecture diagram was a starting point; the transaction and its evidence were what mattered. I bring that habit to Claude integrations. Before discussing how many systems we can connect, I want to follow one request and see exactly what the person making it is allowed to retrieve.
Before I approve a connection, I want to trace whose authority a request carries into the source system. A shared service account, a user-delegated credential and an application role produce different visibility and very different audit trails. If the team cannot explain that difference to the business sponsor and the CISO in plain language, the connection is not ready.
Ask the team to walk one request from the person typing in Claude, through the MCP server or connector, to the source record. Where is the user authenticated? Where is authorization enforced? What evidence remains afterward? I want a diagram that shows trust boundaries and the accountable owner at each step, not vendor logos joined by arrows.
Test with the least privileged person in the room
The riskiest demonstration is the one run by the administrator who configured the connector. Administrators can see everything, so their demo hides exactly the permission mistakes that matter. I ask for an employee with narrow access, such as a branch manager or a care coordinator, and I ask them to request something they should not see.
The denial has to be clean. In healthcare and life sciences work I have watched summaries leak what a filter blocked: a patient count, a name inside an error message, a total that let someone infer a single record. Under HIPAA, a refusal that reveals the shape of protected data is still a disclosure.
Then review the fields actually sent through the workflow. A harmless question can carry personal data, clinical notes or account identifiers the task never needed. Minimize the context, document where processing occurs, and check settings and contracts for your specific deployment rather than a general product page.
Read-only is not the same as low risk
Executives relax when they hear a connector is read-only. Reading and summarizing can still put information in front of the wrong audience. Ask about logs, traces and support bundles, too. A troubleshooting export containing prompts and results quietly creates a second, unrestricted copy of data you worked hard to protect, and it tends to surface in audit findings long after the project team has moved on.
The explanation should work for the people who will review and operate the connection. For a small team, that may be a short access map and a few recorded tests. A service used across several lines of business needs evidence for each distinct access pattern. Reuse the institution’s existing review process and make the new connection visible to the people who already own those controls.
Make failure visible to the person deciding
I ask what the user will see when the source is late, incomplete or unavailable. A response should distinguish a current result from a saved snapshot, and it should not hide a failed lookup behind a plausible explanation. Have the team demonstrate those conditions before approving the connection. The business owner needs to decide which limitations are acceptable for this workflow and when the assistant should withhold an answer.
A connector can return an incomplete page, a stale snapshot or an authorization error from one source while another succeeds. The answer must make those limits visible. A business owner needs to tell “no exceptions found” apart from “exceptions could not be evaluated.” Those sentences lead to opposite decisions even when the screen looks equally calm.
Review recovery as carefully as normal operation. Who rotates credentials? Who validates the connection after a vendor update? Can access be revoked the day the pilot ends? A working setup without a named maintenance owner becomes an unmanaged dependency the moment its builder moves on.
What I ask to see in the approval meeting
I ask for four live examples: one permitted request, one denied request, one ambiguous question and one failed source. Those four tell a board or audit committee more than a long capability list, and they are the evidence I would want if a regulator asked how we knew the control worked. Record the version and configuration that was evaluated.
Then separate approval to connect from approval to expand. A connection authorized for a finance pilot does not authorize new departments, new fields or write actions. Define which changes trigger another review, and revoke a test identity in front of the reviewers.
The CIO's job is to make the conditions of safe usefulness explicit. Teams move faster once those boundaries are written down, because nobody has to argue them again in every sprint.