Workforce AI Security Requirements

This is the workforce (employee-facing) subset. Requirements for building, operating and governing centrally built AI agents and platforms are removed, because they belong in an AI platform engineering requirements set. Agentic workflows employees run inside third-party tools stay in scope.

Removed: onboarding enterprise-built custom MCP servers; agent skill and hook governance; tiered governance for centrally built agents; inter-agent call monitoring; runtime telemetry for built agents; drift of built AI systems; production-readiness and promotion gates; CI/CD pipeline integration; sandboxed agent execution; retirement of built systems; model failover and business-impact evidence; enterprise MCP hosting and reverse-proxy infrastructure.

Kept, scoped to employee use: agent and connector inspection, tool-call governance, connector authentication posture, least-privilege scopes, human approval for high-risk actions, and targeted containment of a single connector or token.

Also out: regulatory obligations as requirements of their own. AI literacy programs, risk-tier classification, worker notification, impact assessments, statutory incident windows and rights over automated decisions belong to a compliance program. A security team evaluates controls, so they are out of scope here. Regulation is mapped per row instead: 52 of the 81 requirements carry an EU or US citation, and the two law columns are filterable, so the regulatory picture stays attached to the control it bears on. The one clause worth keeping as a control, a statutory retention floor, folded into GOV-004.

Also out: identity as a section of its own. Non-human identity lifecycle and credential-misuse detection belong to secrets management and ITDR tooling, and IT service management process is your ITSM platform's job. The three workforce-facing identity requirements that survived that cut turned out to be clauses of other requirements, so attribution now sits inside the audit record (GOV-001) and the connector trace (AGT-006), directory and HR context sits inside policy targeting (POL-001), and administrator SSO sits with role separation (POL-002).

Nothing here is ranked for you. This catalog carries no must-have of its own. A requirement that stops one rollout is a footnote in another, depending on where AI has already spread, which surfaces your people actually use, what your regulator asks of you and what your existing controls already cover. Publishing a house ranking would put a thumb on that scale, so the only priority in the document is the one you set.

Each row takes Must have, Should have or Nice to have from you. Clicking anywhere on a row adds it to your set unrated; the three buttons rate it, and clicking the rating you already gave removes the row again. The rail counts what you have rated and what is still waiting, and your rating is what lands in every export.

The fast path: load a preset or a framework cover to pull a working set in, then rate the ones you care about and leave the rest. A preset scopes the list down; it says nothing about relative importance.

If you are scoring, either a product or your own current state, the Score column in the CSV export works on a simple scale:

• 0 not supported · 1 planned, no artifact · 2 partially met, or shown under someone else's conditions · 3 demonstrated in your environment against your data.

Only a 3 is evidence. Ask for the artifact behind every 2 and 3: a screenshot, an export, a log line, an alert with the prompt summary intact. Where a requirement says "document", the deliverable is a written answer you can keep on file.

Best-fit crosswalk, reviewed by hand. It is not a certification, a conformity assessment, or legal advice, and the references are indicative.

NIST CSF 2.0 subcategories (GV, ID, PR, DE, RS, RC). NIST AI RMF 1.0 subcategories across GOVERN, MAP, MEASURE, MANAGE.

OWASP combines two things from the GenAI Security Project: the Top 10 for Agentic Applications risk IDs, and the adoption tiers from the State of Agentic AI Security and Governance maturity model.

• ASI01 Agent goal hijack · ASI02 Tool misuse · ASI03 Identity and privilege abuse · ASI04 Agentic supply chain · ASI05 Unexpected code execution · ASI06 Memory and context poisoning · ASI07 Insecure inter-agent communication · ASI08 Cascading failures · ASI09 Human-agent trust exploitation · ASI10 Rogue agents
• AT0 Shadow AI on personal accounts · AT1 Vendor embedded assistant (M365 Copilot, GitHub Copilot) · AT2 Platform integrated (custom GPTs, Amazon Q) · AT3 Citizen developer agent (Copilot Studio, Power Automate) · AT4 Code-executing agent · AT5 Custom in-house agent · AT6 Externally extended via MCP · AT7 Multi-agent orchestration · AT8 Federated across organizations

Workforce security lives mostly at AT0 to AT4, plus AT6 wherever employees attach MCP servers and connectors. OWASP treats AT0 as ungovernable in place: it can only be discovered and moved into a managed tier, or blocked, which is why discovery carries so much weight here.

ISO 42001 references Annex A controls (A.2 to A.10) and management-system clauses.

EU and global. The 2026 Digital Omnibus (in force 27 July 2026) deferred stand-alone Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028. Not deferred: Article 4 AI literacy (since 2 February 2025), Article 5 prohibitions (since 2 February 2025, with further prohibited practices from 2 December 2026) and Article 50 transparency (2 August 2026). GDPR, NIS2 and DORA apply on their own timetables.

US state and federal. This is where most workforce AI duties now bite, and the map moves fast:

• Colorado SB 26-189 repealed and replaced the original Colorado AI Act (SB 24-205, enforcement stayed April 2026) with an automated decision-making technology framework for consequential decisions. Signed 14 May 2026, effective 1 January 2027, enforcement contingent on Attorney General rulemaking.
• California is a stack of laws: FEHA automated-decision-system regulations for employers with five or more employees (1 October 2025, four-year record retention); SB 53 frontier transparency and 15-day critical-safety-incident reporting (1 January 2026); AB 2013 generative-AI training-data disclosure (1 January 2026); SB 942 as amended by AB 853 on provenance and latent disclosure (operative 2 August 2026); CCPA ADMT regulations, risk assessments from 1 January 2026, pre-use notices and opt-outs from 1 January 2027.
• Texas TRAIGA (HB 149), effective 1 January 2026, prohibits intentional discriminatory development or deployment and grants a safe harbor for substantial compliance with the NIST AI RMF. That safe harbor is the strongest single reason to keep the CSF and AI RMF columns populated.
• Illinois HB 3773, effective 1 January 2026, amends the Human Rights Act: AI that discriminates in any employment decision is a civil rights violation, ZIP code as a protected-class proxy is banned, and employees must be notified of AI use.
• NYC Local Law 144 (annual bias audit, ten business days' candidate notice), Utah AI Policy Act (generative-AI disclosure), New York RAISE Act (frontier developers over $500M revenue, 72-hour critical-incident reporting, 24 hours where there is imminent risk, effective 1 January 2027), plus state biometric, breach-notification, employee-monitoring and comprehensive privacy statutes.
• Federal: the December 2025 executive order on a national AI policy framework created a DOJ AI Litigation Task Force to challenge state AI laws, and preemption legislation had not passed Congress as at late August 2026. The state duties above still stand, but expect movement. Confirm dates with counsel before relying on them in a contract or filing.

In September 2026 every reference in every row was checked against the published source, one framework at a time. What that turned up, and what changed:

• Existence. One cited CSF subcategory did not exist in CSF 2.0: DE.CM-07, withdrawn from 1.1 and folded into DE.CM-01, 03, 06 and 09. Every AI RMF citation fell inside the real ranges (72 subcategories: GOVERN 19, MAP 18, MEASURE 22, MANAGE 13), and no ISO/IEC 42001 Annex A number was invented, checked against the 38 controls across A.2 to A.10.
• Two systematic misuses. MAP 3.4 had been used across nine discovery rows to mean "we can see AI use on this surface"; it is actually about operator and practitioner proficiency, and those rows now cite MEASURE 2.4 (production monitoring) or MAP 4.1. MANAGE 2.2 had become a generic enforcement bucket across seventeen rows; it is the value-sustainment outcome, so risk treatment now points at MANAGE 1.3 and control identification at MAP 4.2.
• OWASP risks tightened. ASI06 (memory and context poisoning) had been standing in for "sensitive data detection" on seventeen rows whose real subject is data loss or telemetry retention. Sixty-two rows now carry no risk mapping at all, and ASI07 (inter-agent communication) is used once, where agents genuinely talk to each other.
• ISO scope corrected. A.7 governs the data an organization uses to build and improve its own models. Rows about inspecting what employees paste into someone else's model now cite A.9.2 (responsible use) instead.
• Provider duties separated from deployer duties. Several AI Act articles bind providers, not the company whose employees use the tool. Those now read "(provider standard)" or "(analogue)" so they do not imply a duty you carry. Art. 10(5), Art. 26(3), Art. 74 and Art. 49 were wrong for these rows and are gone; frontier-developer statutes (California SB 53, the New York RAISE Act) came out of deployer obligations and remain only as monitoring items.
• One legal error. Colorado SB 26-189 does not carry impact assessments, a risk-management-program duty, or a NIST AI RMF safe harbor. The statute it replaced did. Texas TRAIGA is now the only US safe-harbor citation in the catalog.

Every mapping states its own reason. Each requirement carries one line naming the two or three references that actually carry it and the outcome they deliver, so the basis of the mapping is on the page. The line is the test the mappings had to pass: a reference that could not be justified in one sentence from its published text was removed, which is why the counts are lower than a crosswalk that maps everything to everything. Version 2.0 cut 331 of 670 framework references on that basis, taking the average from eight per requirement to four. Recurring reasons: a statement scoped to a system you already mapped and deployed cannot underwrite discovering tools nobody mapped (NIST AI RMF MEASURE 2.4 went from ten rows to one), data-at-rest is the wrong state for content moving into a prompt, and a duty written for a provider is not evidence for a deployer.

Law citations say which way they run. A legal reference relates to a requirement in one of two opposite ways, and the label on the row says which. Supports means doing the requirement produces evidence toward the obligation. Constrains means the instrument does not endorse the requirement at all, it limits how far you may take it: measuring AI adoption by team engages GDPR Art. 5(1)(c) and employee-monitoring notice law as a ceiling on collection, not as authority to collect. Both marks the rows that sit between a floor and a ceiling, such as telemetry retention between the AI Act's six-month log floor for high-risk systems and minimization. Of the 81 requirements, 36 have supporting citations, 8 constraining, 8 both, and 29 have none. The US state column is mostly empty for the same reason: AI employment-decision statutes govern how decisions about people are made, and they were removed from every row that only shared vocabulary with them.

Framework coverage in one click. The rail has a button per framework that selects the smallest set of requirements touching every reference the catalog maps in it: 27 requirements cover all 34 NIST AI RMF subcategories in use, 28 cover all 47 CSF 2.0 subcategories, 6 cover all ten OWASP agentic risks, 17 cover all 24 ISO/IEC 42001 references. It is a greedy set cover, so the result approximates the minimum, and ties break on catalog order. The framework and regulation dropdowns take a whole framework as well as a single reference, and Add all visible then pulls the matches into your set.

The published text travels with the exports. Hovering a reference on a row shows its statement instantly, clicking one pins the note open, and keyboard focus works the same way. The same text leaves the page: the CSV gains five text columns (one per framework) resolving every reference on the row, the Markdown export gains a References cited appendix, and the JSON gains a referenceText object per requirement. A checkbox in the export card turns that off if you want the identifiers alone. There is also a Download reference library CSV button, which exports all 311 entries with their text and the requirement IDs citing each, selection or no selection — that is the one to hand someone who asks what A.4.3 or MEASURE 2.7 actually says.

Every reference now carries its published text. The Reference library tab holds the complete inventory of each framework, with the verbatim outcome statement for all 106 NIST CSF 2.0 subcategories and all 72 NIST AI RMF 1.0 subcategories, the ISO/IEC 42001 Annex A control and clause titles, the OWASP risk and tier definitions, and a note on every legal instrument cited. Hovering a reference on a requirement row shows the same text, so you can see what a mapping is actually claiming without leaving the row. Every reference in the catalog was machine-checked against that inventory: all of them resolve, so there are no invented or mistyped identifiers.

Version 1.2 made 251 field corrections across 95 of the 100 rows the catalog held at the time. A mapping that was broad but defensible was left alone, on the basis that a best-fit crosswalk should stay readable.

Published by Harmonic Security. We work on this problem for a living and we sell software in this category, so read it as a contribution to the conversation and test it against your own environment.

• It is a collection of insights, with no standing as a standard. It reflects what we see security, IT and GRC teams working through as AI spreads across a workforce: what they inventory, what they detect, where they intervene, what they have to evidence, and what they report upward.
• No platform covers every item, ours included. Some of these requirements describe mechanisms we do not implement. They are in the catalog because teams ask about them.
• Trim it. Eighty-one requirements is a reference set to draw from. Most workable evaluations land between 25 and 45 items, and a short list you test beats a long one that gets self-certified.

Framework mappings are best-fit and reviewed by hand; they are not a certification, a conformity assessment or legal advice. Corrections and additions are welcome. The catalog is maintained as a database behind this page, so a correction reaches every future export.