> ## Documentation Index > Fetch the complete documentation index at: https://docs.kowalah.com/llms.txt > Use this file to discover all available pages before exploring further. # Prompts for security reviewers > Prompts that help infosec, data protection and IT teams use Claude or ChatGPT to review the Kowalah connector and plugin for approval: scopes, data flow, authentication, logging, DPIA screening and the vendor review. These prompts are for the people who decide whether the Kowalah connector and plugin can be switched on: information security, the data protection officer, the system owner and enterprise architecture. They use your own AI tool to do the reading and checking for you, and every answer cites where it came from so you can check it. ## Which review this is Approving Kowalah is a **vendor review as well as a connector review**. Kowalah has its own backend: it stores your programme and operating-model data, runs on its own hosting and uses its own sub-processors. So you're approving a new supplier and application, not only the permissions a connector gets inside a system you've already approved. Our guide [How to get an AI connector approved](https://www.kowalah.com/insights/ai-connector-security-review-pack) explains the two kinds of review and what goes in each pack. The prompts below follow the same structure, and fill in the free [AI connector security review checklist](https://www.kowalah.com/resources/templates/ai-connector-security-review-checklist). **1. Gather what Kowalah publishes** Our [Security section](https://docs.kowalah.com/security/overview.md), the plugin's source on [GitHub](https://github.com/kowalah-dev/kowalah-plugin), and our [sub-processors](https://docs.kowalah.com/security/subprocessors.md). **2. Run the connector review** Scopes, read and write actions, roles, authentication, logging and data flow. **3. Run the vendor review** What Kowalah stores, where, for how long, who processes it, and what happens when you leave. **4. Plan a staged pilot** One team, clear exit criteria, and any wider rollout as a separate decision. > [!TIP] > > Most of these prompts work before you install anything: your AI tool reads our public docs and the plugin source. The ones under **Check the live connector** need a test account connected, so you're checking what the connector actually exposes, not what we say it does. ## Fill in the checklist ### First pass from our docs ```text theme={null} I'm reviewing the Kowalah connector and plugin for approval in our organisation. Read every page under https://docs.kowalah.com/security and the checklist at https://www.kowalah.com/resources/templates/ai-connector-security-review-checklist Treat this as a vendor review as well as a connector review, because Kowalah has its own backend. For every checklist item, tell me: answered, partly answered or not answered; the answer in one or two sentences; and the page you got it from. Don't fill gaps with assumptions. List the unanswered items at the end as questions I should put to Kowalah. ``` ### Turn the gaps into a vendor questionnaire ```text theme={null} From the unanswered and partly answered items, draft a short questionnaire to send to Kowalah. Group the questions under hosting and sub-processors, data stored and retention, separation from other customers, security evidence, model training, exit and deletion, and support and incidents. Keep each question specific enough that a yes or no isn't a complete answer. ``` ## Review the plugin ### What's inside the package Download the [latest plugin release](https://github.com/kowalah-dev/kowalah-plugin/releases/latest), unzip it and attach the folder, or point your tool at the GitHub repository. ```text theme={null} This is the Kowalah plugin package. Review it as a security reviewer. 1. List every skill and summarise in one line what it tells the AI to do. 2. List every connector or server it configures, with the URL and how it authenticates. 3. Flag any instruction that sends data anywhere other than that server, asks the AI to bypass a user confirmation, or tells it to act without the user asking. 4. Flag any script or executable file. Quote the file and line for anything you flag. ``` The skills are plain Markdown instructions. The plugin configures one connector, `https://mcp.kowalah.com/api/mcp`, signed in with OAuth. ### What changed in a new version ```text theme={null} Here are two versions of the Kowalah plugin. Compare them and tell me what changed: new or removed skills, changed instructions, and any change to the connector address or authentication. Tell me whether any change affects what we approved. ``` ## Check the live connector Connect a test account first, using a work email address so it joins your organisation. Run these in a fresh chat with only Kowalah switched on. ### List every tool and what it can do ```text theme={null} List every Kowalah tool available to you in this chat. For each one give its name, whether it reads or writes, what data it returns or changes, and any role or permission limits it describes. Then tell me separately: can any tool delete records, send email or messages, or reach a system other than Kowalah? ``` Compare the answer with [Available tools](https://docs.kowalah.com/plugin/available-tools.md) and [Least privilege](https://docs.kowalah.com/security/data-and-access.md#least-privilege-what-the-connector-can-and-cant-do). ### Separate reads from writes ```text theme={null} Split the Kowalah tools into read-only and write. For each write tool, tell me which roles can use it, whether it asks the user to confirm before it changes anything, and what record it creates or changes. Mark any write that changes data outside our own organisation. ``` Use this to decide whether to start with a smaller group, and what your pilot's exit criteria for write actions should be. ### Test the boundary ```text theme={null} Using Kowalah, try to find a project, opportunity or person from an organisation other than ours. Tell me exactly what you tried and what came back. ``` You should get nothing back from another organisation. Every tool is scoped to the organisations the signed-in user belongs to. See [Tenant isolation](https://docs.kowalah.com/security/data-and-access.md#tenant-isolation). ## Map the data flow ```text theme={null} Using https://docs.kowalah.com/security/data-flow and https://docs.kowalah.com/security/platform-architecture, draw a data flow diagram for the Kowalah connector: the user, our AI platform, the Kowalah connector, Kowalah's backend and its sub-processors. Label what data moves on each arrow, and mark anything that is personal data or could be special category data. Tell me where data leaves the UK, if anywhere. ``` Security teams approve a diagram faster than prose. Check the result against [Data flow](https://docs.kowalah.com/security/data-flow.md). ## Authentication, roles and leavers ```text theme={null} From Kowalah's security docs, explain how a user signs in to the Kowalah connector, how their email domain decides which organisation they join, and how roles limit what they see. Then explain what happens when someone leaves: how their access to Kowalah is removed, and what we need to do in our AI platform's admin settings as well. ``` ## DPIA screening ```text theme={null} Act as our data protection officer. Using Kowalah's security docs and sub-processor list, screen whether the Kowalah connector needs a full Data Protection Impact Assessment under UK GDPR. Cover the categories of personal data involved, the lawful basis we'd likely rely on, retention, international transfers and who the sub-processors are. Say clearly which points the docs answer and which we need to confirm with Kowalah. ``` The operating model can hold people's names, roles and email addresses as process owners, and opportunities carry the name of the person who raised them. Factor both in. ## Plan the pilot ```text theme={null} Draft a pilot plan for the Kowalah connector and plugin. One team of around 20 people for four weeks. Include who gets access and how we restrict it in our AI platform's admin settings, which write actions are in scope, what we log and who reviews it, and exit criteria: usage, accuracy checks, no incidents and a clean log review. End with what evidence we'd need to widen it to the whole organisation. ``` For the admin settings themselves, see [Deploy to your organization](https://docs.kowalah.com/plugin/deploy-organization.md). ## Write the recommendation ```text theme={null} Pull everything from this conversation into a one-page approval recommendation for our decision owner: what Kowalah is, which review type applies and why, the scopes and write actions, the data flow, open risks with a rating each, conditions of approval, and the pilot plan. Mark anything still waiting on an answer from Kowalah. ``` ## Get our answers If your review raises a question our docs don't answer, ask your Kowalah contact or [get in touch](https://www.kowalah.com/contact). We'd rather answer it up front than have it found halfway through your review. > **[Security overview](https://docs.kowalah.com/security/overview.md)** > > The full security pack > **[Security FAQ](https://docs.kowalah.com/security/faq.md)** > > Common reviewer questions, answered > **[Sub-processors](https://docs.kowalah.com/security/subprocessors.md)** > > Who processes your data, and where This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.