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 to get a link to resume or share the assessment later.
• 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.

Most AI governance tools review models and documents, periodically. This decides on individual actions, at runtime — a layer most governance platforms don't ship.

• It's a checkpoint your systems call, not a proxy that intercepts them. Your agent asks the control plane before it acts and gets back allow, review or deny in real time — but it has to ask, and it has to honour the answer. Nothing here sits in the network path or can stop an agent that never calls it. The API and SDKs are how you wire that call in.
• Policy-as-code: risk = action type × irreversibility × data sensitivity × blast radius. Crossing a threshold forces human approval or a block.
• Redaction: the payload you send is scanned for PII and secrets. Anything found is masked in the copy we store and in the payload we hand back, and the detection raises the action’s risk score — an irreversible action carrying sensitive data is pushed to human approval on that basis alone. Being exact: this redacts our record, not your action. Your agent already holds the raw data, so use the redacted payload we return if you want it stripped downstream. The raw payload is never written to the ledger.
• Tamper-evident ledger: each entry is hash-chained to the one before it (EU AI Act Art. 12). Change any past record and Verify chain breaks.
• Kill switch: engage it and the whole fleet is halted (EU AI Act Art. 14(4)).

Compile: your intent is converted into a subject/resource/action-type pattern with a decision (allow/review/deny), matched by simple substring against an action's agent/target fields — the same loose-matching approach Shadow AI Detection and the Vendor Risk Analyzer already use.

Simulate before activating: run the compiled policy against generated test cases (or your own) to see what it would actually decide, before it affects anything real.

Activate: only active policies are consulted by the Agent Control Plane. Activating checks for conflicts with other active policies covering overlapping ground with a different decision. Every version is signed and exportable as a policy bundle; rollback restores the previous version.

Level 0 (Manual) and 1 (Assisted): autopilot only recommends — nothing is ever auto-applied.

Level 2 (Semi-automated) and 3 (Bounded autonomous): the single action type "create a draft control for something an obligation requires but nothing tracks yet" is applied automatically, if enabled and not blocked by an active policy — reversible with one click. At Level 2+, promoting a system with elevated residual risk to production is blocked until you approve it from the inbox below.

Every other detected gap (orphaned system, failing control, overdue re-test) is always just a recommendation — autopilot never assigns an owner, never marks a test as passed, and never overrides the Policy Compiler.

Eight real actions: compile + activate a Policy Compiler policy (deny or require review), archive an MCP-server/tool asset, suspend a Control Plane key that's gone dormant, hold a system out of production, add a control to the Controls Register, or re-run the reassessment daemon for one system. Each does exactly what it says against your actual stored data.

Closed-loop automation (off by default): at automation level 2+, before a candidate applies itself it's projected against real data first — revoke MCP server / disable tool checks the real AI Inventory dependency graph (any production system still depending on it holds it for you); add policy check / add approval gate backtests the candidate policy against your real Control Plane ledger history and only proceeds if the blast radius is under your configured cap. Block deployment, add test case, and re-run evaluation are already narrowly scoped by their own detector, so they apply directly once enabled — same posture Autopilot already gives its one auto-appliable action. Every auto-applied (or held-back) candidate shows its projection in the feed below, and nothing bypasses the Policy Compiler either way.

Not built here, deliberately: Jira/ServiceNow tickets, pull-request generation, credential rotation, or CI/CD-pipeline integration (GitHub Actions, GitLab CI, Terraform, Kubernetes admission control…) — those need real third-party credentials this project doesn't have, the same reason Shadow AI Detection's ~26 connectors weren't built either.

Scanning proposes candidates from five real signals: a failing control on a production system; a high deny/review rate for one agent+tool pair in the Agent Control Plane ledger; an asset whose Control Plane key is already suspended/revoked but the inventory record isn't archived to match; a Continuous Swarm finding that today's policies would let a representative attack through; and a Control Plane key that's gone dormant (active but unused for 30+ days). You can also propose any action manually below.

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.

Getting a compliance deadline wrong is worse than being slow to update it. The watcher classifies news by likely framework/jurisdiction and — when an LLM is configured — drafts a plain-English summary and a suggested Regulatory Horizon entry. By default, you decide what's accurate and supply the final date/impact/action before anything is published.

The one exception: a draft that's already "high confidence" with an explicit, article-sourced date gets re-read by two more independent LLM calls before it's trusted enough to publish unsupervised — all three have to independently agree on both the confidence level and the exact date. Any disagreement — including a panelist simply failing to respond — holds it for your review instead, with every reading shown so you can see exactly where they diverged. Auto-applied items always show a revert button and a link to the public Horizon.

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.

Every agent + tool pair with recent Control Plane traffic gets re-run through a representative attack battery — compromised agent, prompt injection, MCP poisoning, the same real computation as the Digital Twin's "Simulate an adversarial agent" scenario — against your currently active policies, on a schedule.

This never calls a real external model. It can't discover a genuinely new jailbreak — only whether your policy layer would block a representative attack shape. To test a live endpoint's real behavior, use the on-demand tool above.

A pair where an attack gets through is surfaced to the Remediation Center as a candidate policy — with closed-loop automation turned on there, it can even fix itself.

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.