What it is: a simple spreadsheet saved as a .csv file where each row is one decision your AI made about one person or case. You need at least two columns:

• A protected-attribute column — the group to check for fairness, e.g. gender, race, age_band.
• An outcome / prediction column — what the model decided, e.g. 1/0, approved/denied, hire/no-hire.
• (Optional) a ground-truth label column — the correct answer. Add it to also measure equal-opportunity (accuracy parity across groups).

Where to get it: export your model's prediction logs, batch-scoring output, or a table of past decisions from your data warehouse, BI tool, or notebook — most teams already log this.

How to create it: in Excel / Google Sheets add the columns above and Save As → CSV; or in Python: df[['gender','prediction','label']].to_csv('outcomes.csv', index=False).

Proxy scan: every other column in your file (e.g. zip code, school, job title) is checked for association with both the protected attribute and the outcome, using Cramér's V — a real, bounded chi-square statistic, not a model-derived importance score (this tool never sees your actual model, only its outcomes). Flagging a column isn't proof it's a proxy — it's a lead to review.

🔒 Parsed entirely in your browser — the file never leaves your device. Download a blank template ↓

What it does: compares two snapshots of your data to detect drift — when live inputs have shifted away from what the model was built on (a leading cause of silent accuracy decay).

• Baseline — your reference data: the training set, or a known-good period (e.g. last quarter). Upload a CSV or paste a URL.
• Current — recent production data with the same column names. We compute PSI & KS for every shared feature.
• Load only the baseline to run a data-quality scan (missing values, outliers, constants, duplicates).
• URL sources supported: HuggingFace dataset pages (huggingface.co/datasets/…), direct .csv links (GitHub raw, cloud storage), HuggingFace file paths.

Download a blank CSV template ↓

What it does: scores your documentation against the 14 control areas auditors expect, then shows exactly which are present, weak, or missing.

• Link: paste a public URL to a model card (e.g. Hugging Face, GitHub, Confluence) and click Fetch & analyse — we retrieve and scan the text server-side.
• Paste: or paste the text directly — your model card, system card, datasheet, or any governance write-up, even a rough draft.
• Don't have one yet? Paste whatever description exists; the scan tells you precisely which sections to write next.
• You'll get: a completeness score and a present / weak / missing breakdown per control.

What it does: answers your AI-governance questions and proposes step-by-step fixes, grounded in the results from the other tools (your risk tier, fairness/drift findings, and documentation gaps).

• Run the Intake and scanners first for tailored advice — or just ask general questions about the EU AI Act, NIST RMF, ISO 42001, bias, or drift.
• It helps you prepare and evidence compliance; it never claims to make a system “compliant” on its own.

What it does: compiles every result into one audit-ready report — risk classification, applicable regulations across authorities, findings, and a prioritised remediation roadmap (each action has an owner, effort, framework reference, and acceptance test).

• Print / PDF to share with stakeholders; Save privately to resume later. Create a separate expiring summary link when you want to share.
• Run more tools, then click Rebuild to refresh the report and score.

Select a framework below to see its phased rollout. Milestones are marked done, imminent (<90 days), or upcoming. Run the System Intake first and your risk tier will highlight only the obligations that apply to you.

What it does: compiles a structured technical document covering the 14 Annex IV control areas required for EU AI Act high-risk systems — auto-filled from your intake, fairness, and documentation results.

• Run the System Intake and Fairness Scanner first for the richest auto-fill.
• Fill in any blank fields, then click Generate & Download to get a .md file ready for your technical file.
• The card is a governance starting point — have your legal team review before submission to a notified body.

System prompt: the instructions you give the LLM before the user turn. Required by EU AI Act Art. 50 to include an AI disclosure. We check for 6 recommended safety controls.

Adversarial test prompts: one per line — paste typical attack samples from your red-team or known jailbreak libraries to see how many your system prompt can resist. We check 24 injection and jailbreak patterns.

• All analysis runs in your browser. No prompts are sent to any server.
• Pattern matching is a fast triage — not a substitute for live red-teaming with a real model.

A board-ready governance framework document covering five areas:

• AI Governance Team Charter — mandate, composition, and the explicit input → process → output workflow the team operates on.
• C-Suite Accountability Matrix — what each executive owns, what they receive monthly/quarterly, and what they approve.
• IT Governance Controls for AI — data, infrastructure, security, change-management gates, vendor governance, and incident response.
• 12-Month Working Plan — phased roadmap (Foundation → Assessment → Controls → Optimise) with inputs, activities, and deliverables per phase.
• Staff AI Usage Policy — acceptable use, approved-tools register, and high-risk use cases that need governance approval.

Fill in your organisation profile and click Generate Framework. Download as Markdown for your intranet, board pack, or compliance file.

Each iteration runs four steps:

• Observe — reads your current assessment (risk tier, fairness, drift, docs, LLM safety).
• Think — a reasoning model decides the single best next action.
• Act — carries that step out in the loop’s own working notes: flags a gap, records a recommendation, summarises findings so far, or asks you a question. This is the step whose name overpromises — “act” here means writing into the run you’re watching, not touching a live system.
• Evaluate — scores progress against those notes and decides whether to continue.

Where the output goes: nowhere but this screen. The gaps and recommendations exist only for the length of the run and are discarded when it ends. They are not written to your assessment, your readiness score, your dossier, your AI Registry or any policy — copy anything you want to keep, or ask the Copilot to work it into your dossier narrative.

The agent stops when the goal is complete, it needs your input, or it reaches the 6-iteration limit. Run Tool 1 (intake) first so the agent has real data to reason from.

Six scenarios, all data-driven: a policy change is backtested against your real logged Control Plane history; a control failure recomputes real residual risk in memory; a vendor outage or model change walks the real AI Inventory relationship graph to its real dependents; an adversarial agent runs a representative attack battery through the real Control Plane against your real active policies; a new regulation forces a real, already-catalogued upcoming law to "active today" and computes the real coverage gap.

Not built here, deliberately: a fabricated data-breach probability model or human-approval-delay queueing model — this codebase doesn't invent numbers that look precise but aren't backed by anything real.

Every result shows its assumptions and a confidence level, and nothing here ever writes to a system, asset, control, or policy — only to this simulation's own saved result, so you can run and compare as many as you like.

We score every incident against your system's domain, risk tier, and findings — and, when available, against your live Agent Control Plane telemetry (the action types your fleet is intervened on most). Higher relevance = closer to your situation.

• If you've run the System Intake, your profile is pre-filled. Otherwise set it below.
• Each match shows the failure mode and the exact preventive control + framework reference.

We score every tracked development against your jurisdiction, tier, domain and traits (GenAI, personal data, automated decisions), then sort by what's coming soonest and what changed most recently.

• Pre-filled from your System Intake when available — adjust below.
• Each item shows who it affects, the impact, and a concrete next action.

Register a system (or auto-fill from your System Intake). We compute every regulatory obligation that applies to it — across the jurisdictions it operates in — with a countdown to each effective date and the concrete artifact list. Link saved assessments to build the system's governance record.

• Active duties already apply today; imminent ones take effect within 180 days.
• The Control Library below cross-maps NIST AI RMF (72 subcategories), ISO/IEC 42001 Annex A (38 controls) and the EU AI Act artifact set, so one piece of evidence can satisfy several regimes.

What it does: pattern-matches your input against known AI provider key formats, model-endpoint domains, agent-framework imports (LangChain, CrewAI, AutoGen, …), and MCP server configuration — the kind of thing that ends up in a repo without ever going through governance review.

What it doesn't do: confirm a key is live, call any external service, or send your content anywhere — everything runs in your browser. A match is a discovery signal, not proof; review each finding yourself. Nothing is auto-registered or auto-approved.

Matched API keys are redacted before they're ever shown (first/last few characters only) — the real value never leaves the regex match.

What it does: keyword-matches the text against seven governance-relevant clause types. Most are scored on presence (a protection you want to see); "training on your data" is scored the opposite way — language suggesting the vendor trains on your content is flagged as a risk, language explicitly ruling it out counts as a protection.

What it doesn't do: real legal analysis. This is a discovery signal to help you ask the vendor the right follow-up questions, not a substitute for counsel reviewing the actual contract. Nothing is sent anywhere for the scan itself.

Enter a vendor name below to also check the live incident database for anything already reported about them.

Prompt injection & jailbreak attacks are objectively verified: each one asks your endpoint to output a unique, per-run marker token. If that exact token comes back in the response, that's reproducible proof the injected instruction was followed — not a guess.

System-prompt/instruction-extraction attacks are heuristic: this tool never sees your real system prompt, so there's no ground truth to check a "leak" against. Those findings are labeled possible_leak based on refusal-language absence and are meant to be reviewed manually, not treated as confirmed.

Only your own endpoint is contacted — the URL you provide, nothing else. Requests to private/internal/cloud-metadata addresses are refused. The endpoint's hostname is stored with the result; the full URL and any auth header are never persisted.

Results are reachable only via their own private link — there's no public list of everyone's red team runs.

This is a real opcode-level pickle disassembler, not a keyword search. Python's pickle format lets a file name an arbitrary function to call when it's loaded (that's the entire mechanism behind "malicious model file" attacks). We parse the file's actual opcode stream and check every such reference against a curated list of dangerous callables (os.system, subprocess.Popen, eval, …) — a match is dangerous, reported with the exact module and function name found. A reference to an unfamiliar class that isn't on our small allowlist of common ML libraries is flagged for review, not asserted malicious. A file with none of these mechanisms present at all is clean, by construction — not by the absence of a pattern match.

.safetensors files can't execute code by design — that's the whole reason the format exists. We only check the file is well-formed and flag anything suspicious stuffed into its free-form metadata block.

Formats we don't structurally understand (e.g. .onnx) get a shallow raw-byte search only, and we say so in the result — we never report a format we can't actually parse as "clean."

🔒 The file is parsed entirely in your browser. It is never uploaded anywhere.

MIT risk domains are matched by explicit rule against your intake profile (e.g. a generative-AI system maps to "Discrimination & Toxicity" and "Misinformation"; a system with personal or biometric data maps to "Privacy & Security") — every match states exactly which profile fact triggered it, with the real count of matching MIT risk entries and a few real examples.

ATLAS techniques are matched by keyword against MITRE's own technique names and descriptions — the same transparent, pattern-based approach the Shadow AI Detection tool already uses, not a black-box score. A baseline "supply chain" set applies to every system; generative, personal-data, and automated/agentic flags add more. Click a technique to see the real case studies that actually used it.

Run System Intake first if you haven't — this tool reads that profile directly.

Add each model to the inventory and set its materiality tier from business impact × exposure — higher tiers get deeper validation and oversight. For each model, work the validation checklist (conceptual soundness, data quality & lineage, outcomes analysis / back-testing, ongoing monitoring, bias / fairness, explainability, independent validation, effective-challenge sign-off) and record a next-review date.

SR 26-2 (Apr 2026) covers supervised ML; generative & agentic AI are currently outside its formal scope pending an interagency RFI — govern those under the AI Governance & Risk policies. Pair this with the Fairness Scanner and Drift tools for the bias and monitoring evidence.

ECOA / Reg B requires the specific principal reasons for an adverse credit decision — "the model is too complex to explain" is not a defense. When a third-party score/report is used, FCRA adds an adverse-action notice identifying the source.

Disparate impact: the CFPB removed the ECOA "effects test" (Reg B rule eff. 21 Jul 2026), but disparate impact remains actionable under the Fair Housing Act, DOJ and state law (and NY DFS / Colorado for insurance) — so keep testing. Treat it as jurisdiction-dependent, not eliminated.

The checklist covers the seven FS AI RMF domains with representative control objectives and their crosswalks — a starter, not the full ~230-objective set. Track completion per domain. The register captures ICT/AI third-party arrangements DORA expects you to record (register of information), flagging critical providers missing a contract review or exit plan.

Who: anyone shipping a chatbot or voice assistant, generating synthetic audio/image/video/text, publishing deepfakes or AI-written articles, or operating emotion-recognition / biometric-categorisation — where the system is on the EU market or its users or outputs reach the EU.

• Art. 50(1) — tell people they are talking to an AI (provider duty).
• Art. 50(2) — machine-readable marking of synthetic content (provider duty; legacy systems get a marking grace period to 2 Dec 2026).
• Art. 50(3) — disclose emotion recognition / biometric categorisation (deployer duty).
• Art. 50(4) — label deepfakes and AI text published to inform the public (deployer duty).

Everything runs in your browser. Fines for non-compliance reach €15M or 3% of worldwide turnover. Educational aid, not legal advice.

What it does: takes your System Intake profile and the 128-control cross-mapped library behind this platform, and groups controls that are the same underlying practice — described differently by each framework — into one row. Mark each row's status once; it counts toward every framework it lists.

Required vs. recommended: rows are marked Required when your intake profile makes that control a legal obligation (EU AI Act), and Recommended for the voluntary NIST/ISO governance baseline every program should still run.

Saved to your account automatically as you mark rows — reload any time from the link, or export a board-ready worksheet.

Company & product basics, model provenance and training-data handling, data privacy, security posture, AI governance/compliance (EU AI Act tier, NIST/ISO alignment, bias testing, human oversight), reliability, and legal terms — the categories that recur across SIG-style security reviews and the AI-specific questions that have become standard since 2024.

These are your own representations — this tool formats them, it does not verify them.

Every other tool here governs your own AI system. This governs the moment two AI agents from potentially different organizations start talking to each other — the trust primitive an emerging agent economy needs and mostly doesn't have.

• Cryptographic, not vibes-based: the peer's Trust Passport signature is independently re-verified against our signing key — a tampered or forged passport is a hard DENY regardless of policy.
• Policy-as-code: set the minimum assurance level, readiness score, allowed risk tiers, and required frameworks your agent requires of a peer before it's willing to talk to it.
• Same tamper-evident ledger as the Agent Control Plane above (EU AI Act Art. 12) — every handshake is sealed alongside every other agent action, hash-chained and independently verifiable.
• No passport, no verify: by default an unverifiable peer is denied outright, not silently allowed — flip "Require a verified passport" off to hold unverifiable peers for human review instead.