Individuals

Tech Harms Check (Beta) is currently available for individual use and is compatible and recommended for use with a paid Claude plan. Although other MCP-compatible AI assistants can in principle connect to the stack, their behaviour with Tech Harms Check has not been tested.

Organisations

Currently, Tech Harms Check (Beta) is only available in approved organisational environments with prior agreement. It is currently being piloted within a donor institution using Microsoft Copilot. Contact the GPD team for more information about organisational integration and customisation.

Terms of use

Read the Tech Harms Check terms of use.

1.   Check compatibility

The beta version of the Tech Harms Check is recommended for use within Claude.

Ensure you are set-up on Claude and have permission to add custom connectors to your account.

The Tech Harms Check works best on paid-for versions of Claude because it requires high usage to be able to generate reports. Free tier users are likely to exceed their usage limits and a report may not be generated.

2.  Request your access token

You will need an access token to connect the Tech Harms Check to your Claude. A token is an individual credential used to authenticate you.

Complete the Token Request Form to get your token.

You will receive an email with a link to generate it; allow around 10–15 minutes and check spam if necessary.

Keep this email or your token secure and do not share it.

You may need your token again to reconnect the Tech Harms Check in the future.

3.  Add the Tech Harms Check connector to your AI assistant (Claude)

Set-up on Claude should take around 15 minutes.

Open Claude via https://claude.ai/new or the desktop app

Go to Customise/ Connectors/ Add custom connector.

Name it “Tech Harms Check” and enter: https://mcp.techharmscheck.org/mcp

Select ‘Connect’, a web browser will open and ask you to enter your Tech Harms Check token.

Select ‘Allow all tools’. (The assessment uses different Tech Harms Check tools at different stages. If you skip this step the tool will function but will request access to each tool at each of the assessment).

4.   Get your Tech Harms Check report

Start a new conversation on your AI assistant back on its home screen.

Set the level of effort to “low” to reduce usage and time. A full report takes up to five minutes and requires higher usage limits.

Ask it to run a Tech Harms Check on your project or tech. For example: “Run a Tech Harms Check on this project / tool / technology”.

Paste, upload or link to your project information (see below for tips on responsible use first).

Your AI assistant will ask more questions if there are any gaps in information. 

It will also provide you with a summary of the key information it is going to base the your report on. Check that this information is correct before confirming.

Your AI assistant will ask you to submit a password for decrypting your report (see more about privacy below).

The Tech Harms Check uses AI, which can make mistakes, miss important context, or reflect biases in the data it learned from. Anything you share could also create privacy or security risks if it isn’t handled carefully. To use the tool responsibly make sure you: protect people, give relevant information, and check before you act. Here are tips for responsible use of the Tech Harms Check.

Protect people

Use an incognito chat so your conversation isn’t saved to your chat history or memory.

Remove or anonymise personal data such as names, emails, locations, and ID numbers before you share anything.

Use roles instead of identities, e.g. “a local partner organisation” rather than its name.

Take extra care with sensitive subjects like health, sexuality, ethnicity, religion, political views, and migration status.

In conflict, surveillance, or other high-risk settings, leave out anything that could identify or endanger people, such as exact locations, partner names, or security arrangements.

Be cautious about inadvertently sharing your intellectual property or commercially sensitive information.

Give relevant information

Share only relevant information with the Tech Harms Check, including information about:

• The technology and how it’s used.
• The data and what’s collected or processed, and who controls it.
• The people who use it and who it affects, in broad terms. Flag any vulnerable or marginalised groups. Never share details that could put individuals or groups at risk.
• The operating environment: sector, country or region,** **and approximate scale.
• How it’s deployed, including who has access and what decisions it informs.

Don’t worry if you can’t cover everything. The tool will ask follow-up questions to fill any gaps.

Check before you act

When the tool asks you to confirm the details it has picked up, check them carefully and correct anything that’s wrong. Accurate inputs lead to a more reliable assessment.

AI can make mistakes. Treat the report as a starting point, and review and question it before using it to inform decisions.

Check the results with your team and affected communities.

Review any report for sensitive information before sharing it more widely.

 

At the heart of Tech Harms Check is a structured Knowledge Base (KB) developed by Global Partners Digital with the Danish Institute for Human Rights and expert reviewer inputs.

Content

The KB contains these content elements:

• Analytical framework with 104 indicators, 54 human rights and 18 mitigation strategies plus definitions and examples.
• TechnologyXAttributes map of 31 subtypes of technology against 40 possible technology attributes that have the potential to drive tech harms.
• Rights database containing 54 human rights drawn from 9 international human rights instruments and frameworks (see below for full list).
• Harms scoring matrix containing 0-3 scores for all indicators x rights; with a harm description for each indicator and rationale for each score.
• Mitigations matrix with 18 standard strategies, tiered based on deployment context and likelihood of harm.
• Scoring engine: a rule-based engine containing the calculation rules for scores.
• Prompt library with mandatory assessment workflow and rules, the report template, and a glossary of Tech Harms Check terms.
• Report template (a Typst skeleton rendered to PDF) with a standardised structure and content labels showing the source of each piece of content, traffic-light score displays and writing rules.

 Analytical Framework

Sample knowledge base

A sample of parts of the Knowledge Base is available to explore. Access to the full Knowledge Base is available on request.

Workflow

You describe your project including the technology, data, sector, affected people and context.

Your AI assistant maps your project against the Tech Harms Check Knowledge Base and identifies the key parameters it needs to do the assessment.

Your AI assistant checks the details with you and summarises what it has “understood” and asks you to confirm or correct it, and it asks follow-up questions if anything is missing.

The rule-based scoring engine in the Knowledge Base calculates harm scores across five dimensions: Tech, Data, People, Sector and Context. Your AI assistant does not calculate, estimate or change these scores.

Your AI assistant writes a report following a set template which includes the scores, the rights that are potentially harmed, and recommended mitigation steps to reduce harm. Content taken directly from the knowledge base is labelled [KB], and the AI's own analysis of your project is labelled [AI], so you always know where each statement comes from.

You receive your Tech Harms Check PDF report which is generated and encrypted on our servers. You download it as a password-protected PDF through a time-limited link. Read more under privacy.

Likelihood scores

The Tech Harms Check assesses likelihood – not certainty, potential severity or magnitude – of harm.

The KB contains a harms scoring matrix. It includes all indicators across the five dimensions (tech, data, people, sector, context) on the X axis and the 54 rights on Y axis. A score is assigned for every indicator x right i.e. every indicator is scored based on the likelihood that it will harm each of the 54 rights.

Each indicator is assessed and scored in isolation and no other contextual information is assumed for that indicator - for example under Health Sector no assumption is made about the type of technology which might be used.

The score does not take into account any existing safeguards or mitigation measures that might already be in place. Scores are whole numbers from 0 to 3 and are defined as follows.

3 - High likelihood of harm: [High / inherent] There is a strong and reasonably foreseeable likelihood that the indicator will materially affect this right. The impact pathway is inherent to the indicator regardless of deployment context. The indicator is assessed in isolation, no other contextual factors are assumed.

2 - Moderate likelihood of harm: [Moderate / clear but not inherent] There is a meaningful and reasonably foreseeable likelihood that the indicator could materially affect this right in specific and documented deployment contexts. The impact pathway is clear and significant, but not inherent to the indicator in isolation.  

1 - Low likelihood of harm: [Low / indirect] There is a limited foreseeable likelihood that the indicator could materially affect this right. The impact pathway is indirect to the indicator in specific and documented deployment contexts.

0 - No Plausible likelihood of harm: [No plausible connection] There is no credible or reasonably foreseeable likelihood that the indicator would materially affect this right. The impact pathway would be highly speculative or incidental to the indicator.

Calculations

Before calculations are made, the AI identifies which dimensions are active based on user inputs and the following thresholds and actions. For scores to be calculated and a report to be generated, the technology dimension must be active. If none of the other dimensions are specified, your AI assistant will guide you to add this information, but if no other data is provided then these dimensions will be inactive.

Each right receives a dimension score. For example, the Right to privacy is given a score for all five dimensions: tech, data, people, sector, context. Dimension scores are calculated by taking the highest score received under each dimension for each right. For example if the Right to privacy scores 2 x 3s; 4 x 2s and 3 x 1s under the tech dimension, its overall tech score is 3. If a dimension is not active, the dimension receives no score. This highest score approach is used vs other approaches – such as using a mean score – to ensure that where high likelihood is identified for even one indicator, this does not get diluted or overlooked.

The overall score for each right follows a similar highest score approach. The total overall score for each right is calculated by taking the highest score for four of the dimensions: tech, data, people and sector. The context score acts as an amplifying score. Where the context dimension score for a right is higher than any of the other four dimensions, the total overall score is amplified by +1 (capped at 3).

Your AI assistant reviews every right that received a context uplift. The uplift is kept only if the context is likely to make harm more likely through the project's tech, data, people or sector dimensions. If the context only raises the general risk to the right, or would only make harm more severe, the uplift is removed and the right keeps its base score. The AI review can only remove uplifts. It cannot add them or lower a score below its base. Where it's unclear, the uplift is kept. This step removes context uplifts not relevant to the project or technology. The report states which rights were amplified by context and lists any rights where the uplift was not applied.

Content tagging

All content in the report is tagged by source:

KB for content taken verbatim from the knowledge base.

AI for project-specific analysis generated by AI.

INPUT for information defined by the user.

DERIVED for inferred parameters in cases where the AI has taken an extra step and used a user’s inputs and mapped against additional parameters defined by the KB.

Design choices and limitations

The Tech Harms Check is a first step check. It tells you where potential tech harms and human rights impacts might lie and what you could do to minimise these. 

It is not a full scale comprehensive human rights impact assessment (HRIA) or fundamental rights impact assessment (FRIA). It is not a legal assessment or seal of approval. It does not replace other due diligence, including in-depth country-level analysis, participatory assessments, or legal review. 

Although extensive efforts have been made to make outputs as reliable and accurate as possible, Tech Harms Check involves AI and AI gets things wrong. Always double check and interrogate responses especially when you are using them to inform your decisions. Please use it responsibly.

Some potential harms may require specialist analysis and engagement with affected people. 

Scores are indicative of likelihood. They do not tell you the certainty, potential severity or magnitude of harm, how many people could be affected, whether an impact is reversible, or whether a project should proceed.

Scores do not account for any safeguards or mitigation measures already in place.

Scoring is cautious by design. The Tech Harms Check aims to capture any right that could plausibly be affected. Scores are based only on the limited set of parameters that the knowledge base is built on, so they can’t reflect every nuance of your project. The AI is guided to help account for these, but some rights flagged as high may turn out to be less of a concern in practice. A high score means a right needs careful and/or further examination, not that it is definitely being impacted.

Some harms cannot be mitigated. The mitigation strategies provided are suggestions only and are not a guarantee. 

This KB for the beta version of the Tech Harms Check does not include deployment factors – such as the tech or data's scale, management and level of human oversight, and access by other actors. Indicators for these were included in earlier prototypes, but failed to produce accurate results. These factors are still important for a full human rights impact assessment, so consider them alongside your report and in your mitigation strategies.

Testing and updates

A pre-release build of the connector was evaluated within Claude through user acceptance testing and accuracy testing, with accuracy validated against a sample of projects. Identified issues were resolved and retested before release of this beta version.

Your prompts stay with your AI assistant. What you type and any documents you share aren't sent to the Tech Harms Check. Your AI assistant still processes them under its own terms, so follow the responsible use tips.

No access to your accounts. The Tech Harms Check can't see your files, email or other systems.

Secure sign-in. You need your own account to use the tool. When you sign in, you're given a temporary access key that expires after a short time, which keeps your access protected. Organisations can also arrange for staff to sign in with their work accounts.

Your account details. To give you access, we collect your name and email address. These are stored securely by Brevo, our access management provider, and used only to issue, manage and, if needed, cancel your access. We use them for marketing only if you opt-in.

Your AI assistant generates the report text, the PDF is generated on our servers and encrypted straight away with a password you choose. Only the encrypted version is stored, and the password is never saved.

Only you can open it. Your report is unlocked in your own browser using your password, so the readable version only ever appears on your device. Keep your password safe, as we can't recover it.

Reports are deleted after 24 hours. No personal details are stored with them.

Nothing is used for training. The tool doesn't record what's in your assessment. Hosted in the EU. The tool and your reports are hosted in Germany, and your account details are held in the EU. All data is protected under GDPR.

Data retention policy. See terms of use.

 

Architecture

The Tech Harms Check stack exposes a set of tools to your own AI via the Model Context Protocol (MCP). These tools cover scoring, knowledge-base queries and PDF generation. Any MCP-compatible AI can connect and call these tools to carry out a structured screening of potential tech harms. The stack performs no inference, so all language-model work stays on your AI platform. It comprises three containerised, provider-agnostic services:

MCP server (Node.js): An MCP resource server that exposes the THC toolset and validates the bearer token on every call.
Directus: The system of record for the Tech Harms Check Knowledge Base, covering rights definitions, technology–harm relationships, the scoring matrix, mitigation recommendations and prompt templates. The MCP server holds a read-only service token, so the tool path cannot modify framework content.
Ory Hydra (OAuth 2.1): A self-hosted authorisation server with a custom login/consent service. It issues short-lived access tokens and answers the MCP server's token validation, which is cached for 30 to 60 seconds.

Data exchange

A typical request flows as follows. Your AI sends a tool call with a bearer token, the MCP server validates the token against Hydra, reads from Directus as needed and returns structured JSON. The only persisted output is the encrypted report bundle.

Tool calls: Each call carries only a tool name and JSON arguments, such as indicator codes, filters or scoring inputs. Prompts and source documents never leave your AI platform.
Report generation: The generate_pdf receives only the report body your AI has written (project name, date, assessment text and scores). Source documents are never sent.
Metadata: Each request also carries the OAuth bearer token and standard HTTP transport data, such as IP address and user agent.
No reverse path: The stack requests no Graph API scopes, holds no workspace credentials and accepts no file references or URLs. The MCP server's only outbound connections are to Directus and Hydra.

Identity

The Tech Harms Check stack uses OAuth 2.1 with PKCE for sign-in. When a user makes a request, the server only checks that their access token is valid. It sees an internal user ID, the client ID, the permissions granted and when the token expires, and nothing else about the user.

Individual users: Each user signs in with their own Tech Harms Check account. User names and email addresses are held in Brevo and used solely to issue and revoke access tokens. They are not used for marketing or any other purpose. The MCP server does not receive this data and sees only the internal user ID. Find out more about data retention, access and deletion requests in terms of use.

Organisational users: Sign-in can be linked to your organisation's identity provider (e.g. Entra ID), so users log in with their work accounts and your own MFA and Conditional Access policies apply. This would be agreed contractually.

Privacy and encryption

Encryption: The PDF is bundled with a knowledge-base Excel file and encrypted server-side with AES-256-GCM, using a key derived from the user's password via PBKDF2. The password is used once and never stored.
Decryption: The PDF is rendered and encrypted in memory on the server, and only the encrypted file is stored and delivered. Decryption happens entirely in the user's browser via the Web Crypto API, so the unencrypted PDF exists only on the user's device.
Retention: Encrypted bundles are held in an on-server SQLite database under a randomised URL and deleted automatically after 24 hours. No personally identifiable information is stored with them. Tool arguments are processed in memory only.
Logging: Each request logs a timestamp, token ID, HTTP method and path, with a per-token counter for metering. There is no content logging, analytics, telemetry or model training. The log-retention period is 24 hours. For customised iterations, it is agreed contractually.

Hosting and third parties

The Tech Harms Check stack is hosted on Hetzner servers in Germany under the techharmscheck.org domain. Application data, logs and backups remain within the EU and are subject to GDPR. The stack is operated by DOT • STUDIO on behalf of GPD. No subcontractors have operational access. Using the Tech Harms Check stack consumes no additional paid tokens, as all inference runs under your own existing AI licence.