AI Security Wiki: Governance, Risk, Standards and Test Cases

What it is

The AI Security Wiki is an "implementation layer" for enterprise AI governance, written by Nachiket Sathaye and Ankush Jain, two individual practitioners. It does not replace the catalogues and standards that say what to worry about and what the law expects. It supplies control objectives, audit evidence, audit procedures and test cases. The page is the landing and navigation hub. The controls, risk register and test cases sit on linked pages that were not part of the fetched text.

How it works

The wiki prescribes a per-use-case sequence (section 16):

1. Start from the lifecycle stage of the AI initiative.
2. Register the use case or tool before implementation or procurement.
3. Complete the risk assessment and apply the required control objectives.
4. Apply the domain standard that matches the implementation pattern.
5. Assess any third-party service, platform, plugin, model or integration as a vendor.
6. Run the required PoC and security tests before production.
7. Collect evidence continuously.
8. Update the risk register whenever controls, scope, vendors, models or data flows change.
9. Feed incidents, findings, threat intelligence and regulatory change back into the controls.

Its policy hierarchy places eleven standards under one enterprise AI security policy. These include acceptable use, AI-assisted development, runtime application security, agentic tool governance, sovereignty/data residency, the vendor framework, testing, and audit/evidence.

It also sets a rule on vendor material (section 14). The wiki publishes no product profiles. Controls stay vendor-neutral. Your own vendor records should hold supplier limitations, contractual evidence, residency details, PoC results, known gaps, compensating controls and residual-risk decisions, and should reference control objectives and tests rather than redefine them.

What to do

• Use it as a template source: copy the register, control-objective, vendor-scorecard and evidence-checklist structures into your own GRC tooling.
• Keep supplier-specific findings in your own records, linked to the wiki's control IDs.
• For regulated markets, start from the relevant regional hub (role guide, templates, crosswalk), then verify each instrument against the primary law.

Caveats

• The sovereignty lens is UAE/GCC-first. The design principles name UAE residency, and the GCC hub is described as listing instruments with a "verification status". The other regional hubs are described only as role guide, templates and crosswalk, so expect uneven depth.
• The wiki cites FINOS AIGF identifiers for traceability but does not reproduce that framework's text (CC BY 4.0).
• Sections on the roadmap, success metrics, key control domains and governance were empty in the fetched text. Their content is unverified here. The page says control-effectiveness metrics live in a separate Assurance page.
• The authors give no evidence that the 653 test cases have been validated in production. Treat them as a starting library and pilot a subset.