Compliance & Attestation¶
CyberArmor.AI maps enforceable controls to established regulatory frameworks and preserves tenant-scoped assessment evidence in PostgreSQL — evidence bound to the control decision that produced it, not gathered after the fact.
Framework policy packs¶
The compliance engine ships 44 framework policy packs. Each turns a framework's AI controls into enforceable policies in one click (measured on production 2026-10-13: 45 frameworks are assessed; 44 carry a policy pack; SANS/CWE Top 25 is assessed only).
| Framework | Version | Jurisdiction | Controls in pack |
|---|---|---|---|
| NIST Cybersecurity Framework | 2.0 | United States (NIST, adopted internationally) | 4 |
| NIST 800-53 | Rev 5 | United States (federal) | 4 |
| NIST AI Risk Management Framework | 1.0 | United States (NIST, adopted internationally) | 4 |
| CMMC Level 3 | 2.0 | United States (defense supply chain) | 4 |
| NYDFS 23 NYCRR 500 | 2023 Amendment | United States - New York | 3 |
| ISO 27001 | 2022 | International (ISO/IEC) | 4 |
| CIS Controls | v8 | International (Center for Internet Security) | 3 |
| CSA Cloud Controls Matrix | v4.0 | International (Cloud Security Alliance) | 4 |
| OWASP Combined | 2024 | International (OWASP) | 5 |
| PCI-DSS | v4.0 | International (PCI Security Standards Council) | 5 |
| SOC 2 Type II | 2022 | United States (AICPA) | 4 |
| EU GDPR | 2016/679 | European Union | 2 |
| CCPA/CPRA | 2023 | United States - California | 1 |
| SEC Cybersecurity Disclosure Rules | Release No. 33-11216 (2023) | United States (SEC) | 3 |
| FINRA Cybersecurity Program | Report on Cybersecurity Practices | United States (FINRA) | 4 |
| ISO/IEC 42001:2023 (AI Management System) | 2023 | International (ISO/IEC) | 4 |
| HIPAA Security Rule | 45 CFR Part 164 (Subparts C & D) | United States (HHS) | 4 |
| EU AI Act (Regulation (EU) 2024/1689) | 2024/1689 | European Union | 4 |
| MAS Technology Risk Management (Singapore) | 2021 + Cyber Hygiene Notice | Singapore | 3 |
| HKMA TM-G-1 and C-RAF 2.0 (Hong Kong) | TM-G-1 / C-RAF 2.0 | Hong Kong SAR | 3 |
| PBOC / NFRA with MLPS 2.0 (China) | GB/T 22239-2019 | China (mainland) | 3 |
| UK GDPR / DPA 2018 with FCA-PRA operational resilience | DPA 2018 + PS21/3 | United Kingdom | 3 |
| Australia: Privacy Act/APPs, APRA CPS 234 and CPS 230 | CPS 234 + CPS 230 | Australia | 3 |
| Japan: APPI with FSA and FISC guidelines | APPI (as amended) + FISC | Japan | 3 |
| South Korea: PIPA, EFTA regime and ISMS-P | PIPA (as amended) + ISMS-P | South Korea | 3 |
| Canada: PIPEDA, Quebec Law 25 and OSFI B-13 | PIPEDA + Law 25 + B-13 | Canada | 3 |
| Brazil: LGPD with BACEN cyber security resolutions | Law 13.709 + Res. 4.893 | Brazil | 3 |
| Thailand: PDPA with Bank of Thailand IT risk | PDPA B.E. 2562 | Thailand | 3 |
| Malaysia: PDPA 2010 and BNM RMiT | PDPA 2010 (as amended) + RMiT | Malaysia | 3 |
| Indonesia: UU PDP with OJK technology regulation | Law 27/2022 + OJK | Indonesia | 3 |
| Philippines: Data Privacy Act 2012 with BSP IT risk | RA 10173 + BSP | Philippines | 3 |
| Nigeria: NDPA 2023 with the CBN cybersecurity framework | NDPA 2023 + CBN RBCF | Nigeria | 3 |
| South Africa: POPIA with SARB and the Cybercrimes Act | POPIA + Joint Standard | South Africa | 3 |
| Kenya: Data Protection Act 2019 with CBK guidance | DPA 2019 + CBK | Kenya | 3 |
| Ghana: Data Protection Act 2012 with the BoG directive | Act 843 + BoG CISD | Ghana | 3 |
| Egypt: PDP Law 151/2020 with CBE cybersecurity rules | Law 151/2020 + CBE | Egypt | 3 |
| African Union Malabo Convention (continental baseline) | Malabo 2014, in force 2023 | African Union (continental) | 3 |
| Pakistan: Deployment Readiness and Shared Responsibility | Rev.1 2026-09-30 — planning baseline | Pakistan | 3 |
| Pakistan: National AI Policy 2025 | 2025 — approved policy; thematic mapping | Pakistan | 3 |
| Pakistan: Information Security Framework (PISF) 2026 | 2026 — thematic mapping | Pakistan | 3 |
| Pakistan: Cyber Security Policy 2021 and CERT Rules 2023 | 2021 / 2023 — thematic mapping | Pakistan | 3 |
| Pakistan: Cloud First and Public Sector Procurement | 2022 / 2024 — deployment-specific | Pakistan | 3 |
| Pakistan: SBP Cloud Outsourcing and Payment Technology Risk | 2023 / 2025 — regulated-entity applicability | Pakistan | 3 |
| Pakistan: Privacy and Data Governance Preparation (Draft) | Planning baseline — drafts are not enacted law | Pakistan | 3 |
An eighteenth framework, SANS/CWE Top 25, ships its controls and assessment but deliberately has no policy pack. Its controls are secure-coding practices in the customer's own SDLC — memory safety, SAST configuration, parameterised queries — which this product cannot observe in AI traffic. It is satisfied by uploaded attestation documents rather than by an enforced policy, and is counted separately for that reason.
Each pack provides enforceable control templates that map compliance requirements to runtime policy — controls that become executable decisions, not documents.
Applying a policy pack that needs artifacts¶
Some pack controls read a tenant list (an artifact) by name, written in the
policy as $artifact:<name> — for example "Block Unvetted Third-Party AI Tools"
and "Monitor Anomalous AI Usage" need approved_providers. If the list does not
exist yet, the control cannot be applied, and because the policy was never
created there is nothing to look the name up in. CyberArmor.AI therefore names it
for you:
- In the customer portal open Compliance → Policy pack for the framework. Any proposed control that needs a list you do not have shows Not applicable until this artifact exists, with the exact name (and a Copy name button), its type and format, example values and what the control does with it. The same details appear next to any control that Apply skipped.
- Click Create this artifact. The Artifacts editor opens with the name and type filled in and the items empty; the examples are shown only as a placeholder and are never saved for you. Enter your own values and click Create.
- Re-open the policy pack and click Apply Selected again. The control that needed the artifact is now created; controls already applied are skipped.
The API returns the same information as missing_artifacts on each proposed
template (GET /api/customer/compliance/frameworks/{id}/policy-pack) and on each
skipped entry in errors (POST .../policy-pack/apply), each with name,
type, format, examples, purpose, default, reason and
create_url_hint. If the preview reports artifact_inventory_checked: false,
the tenant's artifacts could not be read and the list was not checked.
Artifacts each policy pack needs¶
| Artifact name (type exactly) | Type | Format | Example values | What the control does with it | Default | Templates that need it (packs) |
|---|---|---|---|---|---|---|
approved_providers |
domain_list |
List of domain names, one per line, no scheme or path (the AI destinations your organisation has approved). | chat.openai.com, claude.ai, gemini.google.com |
Allowlist for the 'block/monitor unapproved AI provider' controls: traffic to a known AI destination that is NOT on this list is blocked or logged. Leaving out a provider your staff use blocks it. | Created automatically when the pack is applied IF at least one AI Provider is configured. Otherwise create it first. | Block AI Providers Outside the Approved List (27); Block AI Providers Without a Business Associate Agreement (1); Block Unapproved AI Providers (1); Block Unapproved Vendor AI Tools (1); Block Unvetted Third-Party AI Tools (2); Monitor Anomalous AI Usage (2) |
known_ai_destinations |
domain_list |
List of domain names, one per line, no scheme or path (every host that counts as an AI destination). | chatgpt.com, api.anthropic.com, perplexity.ai |
Scope for the AI-destination controls: only traffic to a host on this list is considered AI traffic, so the controls never match ordinary browsing. Add self-hosted or niche AI providers here. | Created automatically when the pack is applied. Nothing to create. | Block AI Providers Outside the Approved List (27); Block AI Providers Without a Business Associate Agreement (1); Block Unapproved AI Providers (1); Block Unapproved Vendor AI Tools (1); Block Unvetted Third-Party AI Tools (2); Log All AI Activity (6); Maintain AI Activity Audit Log (1); Maintain AI Activity Audit Trail (2); Monitor Anomalous AI Usage (2); Monitor External AI Service Activity (1); Monitor Recognised AI Interactions (7); Record AI Activity for the ePHI Audit Trail (1); Record Every AI Interaction (20) |
secret_classes |
keyword_list |
List of CyberArmor.AI detection class names, one per line, each starting with 'secret.'. | secret.api_key, secret.private_key, secret.aws_access_key |
Which detected secret classes the 'Block Credential and Secret Exfiltration' control blocks in prompts and uploaded files. Create it only to narrow or extend the built-in list. | Built in. Nothing to create; create it only to narrow or extend the list. | Block Credential and Secret Exfiltration (1) |
Generated from PACK_ARTIFACTS in services/compliance/policy_packs.py across all 44 policy packs by scripts/docs/gen_pack_artifact_table.py; do not edit by hand.
Evidence & assessments¶
Evidence and assessment reports are DB-backed and tenant-scoped:
- per-request evidence submission and retrieval
- per-framework assessment reports, scored and stored
- evidence tied to the enforcement decision (actor, request, policy, response)
| Endpoint | Purpose |
|---|---|
GET /frameworks |
list available frameworks |
GET /frameworks/{id}/policy-pack |
control templates for a framework |
GET /frameworks/{id}/controls |
controls with evidence keys |
| submit / get evidence per request | attach and retrieve request-scoped evidence |
Out-of-band verification for payment instructions¶
A payment instruction above a threshold the firm sets is held until somebody
phones the counterparty back on a number from the firm's own directory of
record, and two named people who are not the initiator confirm it. Completing
that callback satisfies FINRA-FRAUD-1 on platform-observed evidence.
The directory is the control¶
A deepfake-enabled wire-fraud call works by supplying a plausible callback number alongside the instruction. Verifying against a number the requester gave you verifies nothing.
There is no code path anywhere in the product that turns a caller-supplied number into a callback target. A counterparty absent from the directory produces a held payment and an explicit refusal to place the call — which is a different operational state from a payment awaiting one, and is reported as such. Changing a number of record is restricted to a tenant administrator and attributed.
Lifecycle¶
required → pending → attested | refused | expired
An abandoned attestation recomputes to expired from the clock rather than
waiting for a sweep. The compliance evidence key is set only by a completed,
re-verified attestation — a tenant that asserts this control passed is
overridden by the platform's own reading of its records, per the provenance
ranking above.
| Endpoint | Purpose |
|---|---|
POST /payments/events |
observe a payment instruction; returns whether it is held |
GET /attestations |
the approver queue for a tenant |
GET /attestations/{id} |
one attestation and its state |
POST /attestations/{id}/callback/begin |
record that a callback was placed |
POST /attestations/{id}/callback/complete |
record its outcome |
GET /attestations/directory/{tenant_id} |
the directory of record |
PUT /attestations/directory/{tenant_id} |
amend it (tenant administrator only) |
GET /payments/{external_ref}/resolution |
release / hold / cancel / unknown_to_us |
Approvers are emailed when a payment is held, and the queue records whether that notification actually went out — a notification that silently failed must not read as one that was delivered. Every state change is written to the signed audit chain.
CyberArmor.AI holds no funds
Recording an outcome produces the evidence. Releasing or cancelling the payment happens in the system that holds it; the resolution endpoint exists so that system can poll for the answer. Nothing here moves money.
This control requires no media analysis and works whether or not the voice on the call was synthetic. See Media Authenticity for what can and cannot be established about a file.
Validation checklist¶
GET /frameworksreturns all 18 registered frameworks (17 of them with policy packs) includingiso42001,sec-cyber, andfinra-cyberGET /frameworks/iso42001/policy-packreturns enforceable control templates- submitted evidence for a request is retrievable and persists across a service restart
- a payment above the tenant's threshold returns held, and one below it does not
- a counterparty absent from the directory returns held with an explicit refusal to place a call, not held-awaiting-callback
FINRA-FRAUD-1reportsplatform_observedafter a completed callback, and is not satisfied by a tenant asserting it
See also Evidence Export.