CyberArmor Platform — Capability Definitions¶
42 capabilities: what each one means, the risk it addresses, where it runs, and its honest status¶
Audience: CISOs, security architects, risk and compliance leaders, and investors. Date: 2026-08-19
How to read this. For every capability: a plain-English definition, a concrete use case, the risk it addresses, an honest status, and — where a limit exists — the limit, stated here rather than discovered later. Teams flags which group at a large enterprise typically owns the problem: SEC = cybersecurity, RISK = risk/compliance, AI = the business/AI-agent team, ENG = engineering/dev tooling.
Status legend (from our engineering status page, reconciled against the source repository): Working — runs end-to-end today, tested. Configurable — implemented; needs environment/config to activate. Pilot — functional; being exercised with design partners. Roadmap — not built yet.
On statuses. We publish maturity per capability rather than a single "available" claim, because the distinction between working today, needs configuration, in pilot and not built is the distinction a buyer actually needs. Where a capability has a known boundary — a format we do not parse, a surface that carries request context only — that boundary is written into its entry.
Part 1 · Prevent and enforce (1–19)¶
1 · Pre-ingestion trust gate — checked before the model reads it — Working · Teams: SEC, AI
A control point that evaluates a URL or piece of external content before any consumer — a human, a browser, an application, or an AI agent — ingests it. The gate canonicalizes the destination, checks reputation, fetches the content safely, scores it for phishing, hidden prompt injection, promptware, and IOCs, then returns a policy verdict: allow, warn, redact, sandbox, block, or isolate. This differs from every runtime prompt filter: those inspect content as the model is already consuming it; the gate decides before exposure, in a sealed environment. Use case: your internal Claude deployment or the customer-facing agent needs web context; a page carrying a hidden instruction is blocked or redacted before it ever enters model context. Risk: indirect prompt injection — the attack class where the payload arrives in content, not from the user.
2 · Sealed / sandboxed fetch of external content — Working (production requires network-isolated deployment, documented) · Teams: SEC
When the gate fetches a URL, it does so with no user credentials, no cookies, no session — GET-only, size- and time-capped, every redirect hop re-validated against SSRF rules. The content is examined in a sealed context that has nothing to steal. Use case: a link in a customer email or ops ticket is evaluated without the analyst's session ever touching it. Risk: SSRF into internal services, credential replay, drive-by content executing in a privileged context.
3 · Sandboxed detonation of untrusted URLs in an isolated browser — Working (must run on an isolated network segment; Kubernetes NetworkPolicy hardening on roadmap) · Teams: SEC
For URLs that static fetching can't judge, a one-shot Chromium instance (Playwright, on a dedicated network with no route to internal services) actually renders the page — exposing JavaScript-built DOM, CSS-hidden text (display:none payloads), and zero-width/Unicode-tag encoded instructions that never appear in raw HTML. Use case: deep-mode check of an unknown or suspicious URL before an AI agent is allowed to read it; forensic re-check after an analyst flags a miss. Risk: injection payloads that only exist after the page renders.
4 · Model-file static inspection without execution — Working on the endpoint agent · Teams: SEC, ENG
When a serialized model file (.pkl, .pt, .ckpt, .joblib, and similar) lands on a machine, the agent disassembles its pickle opcode stream — it never loads, unpickles, or executes the file — and reports the specific import that would give the file's author code execution on load. It recognizes how payloads actually serialize (e.g. posix.system, not os.system) and emulates the pickle memo so a payload can't hide behind a memoized string. .safetensors is deliberately not flagged — that format cannot carry code. Known limits, stated up front: it is an unsafe-import detector keyed on a denylist, not a proof of safety; HDF5/Keras coverage is a narrow heuristic; .npz members are not parsed. Use case: a quant downloads a checkpoint from Hugging Face; the verdict arrives the moment the file is written, on the workstation — not weekly, in a cloud registry. Risk: a poisoned checkpoint is arbitrary code execution the moment someone loads it.
5 · Dataset supply-chain scanning — Working (inventory) / artifact scanning as row 4 · Teams: SEC, ENG
Two halves: the AI Bill of Materials (A-BOM) inventories models and datasets across endpoints, code repositories, cloud sources (including e.g. BigQuery datasets and object storage), and artifact registries — so you can answer "what AI artifacts exist here and where did they come from"; and serialized data artifacts get the same static code-execution inspection as row 4. Honest scope: this is provenance inventory plus embedded-code detection — not statistical data-poisoning analysis of training sets. Use case: an examiner or internal audit asks which models and datasets are in use and their sources; the A-BOM answers from live inventory. Risk: unknown/untracked AI artifacts and code smuggled inside data files.
6 · Indirect prompt-injection / hidden-instruction detection — Working · Teams: SEC, AI
Detection of instructions hidden inside content: zero-width characters, homoglyphs, Unicode-tag encoding, CSS-hidden text, encoded segments — normalized and extracted before scoring, with an ML classifier plus a heuristic ensemble, and session-level correlation that recognizes multi-turn "promptware" attack chains rather than judging each message in isolation. Use case: a web page, resume, or document pulled into your internal Claude's context carries invisible "ignore your instructions" text; it is caught at ingestion. Risk: the model obeys content instead of the user — currently the top practical attack on deployed LLM applications.
7 · Runtime prompt guardrails / LLM firewall — Working · Teams: SEC, AI
The conventional layer of this category: inline screening of prompts and requests for injection, jailbreak attempts, toxicity, and sensitive data, at the proxy, gateway API, SDK, or RASP layer. This is table stakes for the category, and capabilities 1–6 are what sit in front of it. Use case: every prompt to an approved provider passes policy before it leaves. Risk: jailbreaks and malicious prompts reaching the model unscreened.
8 · Egress DLP for AI — 33-class catalog (27 structured + 6 NER) — Working · Teams: SEC, RISK
Data-loss prevention tuned for AI egress: 27 structured detector classes (SSN, credit card, bank routing, passport, driver's license, DOB, and a full secrets family — AWS/GCP keys, GitHub/Slack/Stripe/OpenAI/Anthropic tokens, JWTs, private keys) plus 6 NER classes (person, location, organization, IP, URL, crypto address) plus semantic similarity detection. Context-aware: it knows an email address in a login form is authentication, not a leak — so it doesn't redact your credentials into a broken login. Actions are graded: warn, redact (with optional per-tenant HMAC pseudonymization so auditors can correlate without recovering the value), or block. Use case: an employee pastes a customer letter containing an SSN into a chatbot; the SSN is redacted before the request leaves. Risk: NPI/PII/secrets in prompts — the #1 reason banks ban AI tools outright.
9 · PHI detection + clinical de-identification (HIPAA Safe Harbor) — Pilot (recently added) · Teams: RISK
Detection of protected health information classes and de-identification aligned to the HIPAA Safe Harbor method, backed by a HIPAA policy pack (22 controls). For a financial-services buyer this is not the core purchase — it demonstrates the regulated-vertical depth of the same DLP engine, of which the FINRA and SEC packs are the finance equivalents. For healthcare-adjacent workflows it is the core purchase. Risk: PHI in AI traffic for any healthcare-adjacent workflow.
10 · Model-response inspection, not just the prompt — Working on proxy surfaces · Teams: SEC, AI
Most tools only inspect what users send. This inspects what the model returns: command-execution patterns (curl | bash, powershell -enc), XSS/script payloads, browser-data exfil sinks, PII in output, and the dangerous-code-generation pattern generic classifiers miss (file-walk + encrypt + delete — ransomware shape). Honest scope: response inspection ships on both proxy surfaces; the browser extension, SDK, and RASP surfaces carry request context only today. Use case: your coding assistant returns a "fix" that quietly exfiltrates browser data; the response is flagged/blocked before it renders. Risk: the model as an attack vector into your environment.
11 · File-upload content inspection — Working with documented format limits · Teams: SEC, RISK
Files being uploaded to AI services are opened and inspected — not just fingerprinted by name/type — with a dedicated block uploads policy action. Honest scope: text-class files and documents open in Word/Excel/PowerPoint are read; PDF, DOCX-at-rest, and OCR parsing are not built yet. Use case: an analyst drags a client spreadsheet into a chatbot; content inspection decides redact/block, not the filename. Risk: bulk exfiltration via attachments — the highest-bandwidth leak path to AI services.
12 · Seven graded policy actions at the moment of use — Working · Teams: SEC
Enforcement is graded, not binary: allow · monitor · warn · redact · block-uploads · block · isolate (the trust gate additionally enforces sandbox). The policy builder only offers actions the selected surface can actually enforce, so an unenforceable rule can't be saved. Use case: start a new control in monitor, move to warn, then redact, then block as confidence grows — the rollout path a change-averse enterprise actually follows. Risk: binary block/allow tools get switched off after the first false positive; graded ones survive.
13 · Every verdict names the engine that produced it — Working (recent) · Teams: SEC
Every detection verdict carries attribution: which engine fired (ML classifier, heuristic ensemble, reputation feed, hidden-text extractor), with what score, and why. Analysts see "credential_harvest 0.85 — brand/domain mismatch + credential form," not an unexplained "blocked." Use case: your SOC triages an alert in seconds and tunes the specific engine that's noisy instead of distrusting the whole product. Risk: unattributed verdicts are unactionable — and unactionable tools get ignored.
14 · One rulebook, centrally authored, enforced on every surface — Working · Teams: SEC, RISK
Policies are written once against a governed field registry and compiled to each enforcement surface — browser extension, proxies, endpoint agent, RASP, trust gate, gateway API. Every policy field must have a real producer on the surface it targets (this is enforced by tests), so rules can't silently reference data a surface doesn't have. Use case: "no SSNs to unapproved AI providers" is one rule, enforced identically in the browser, the IDE, and server-side apps. Risk: per-surface rulebooks drift, and the gap between them is where incidents live.
15 · Tenant-set fail mode, fail-closed by default — Working · Teams: SEC
When a detection or policy component is unreachable, you decide per tenant whether traffic fails closed (blocked until inspection is restored — the default) or fails open (availability first). It's a visible setting, not an undocumented behavior. Use case: fail-closed for trading-floor endpoints, fail-open for a low-risk pilot group. Risk: security tools that fail open silently are a bypass; ones that fail closed unexpectedly are an outage. Either way, it should be your call.
16 · Endpoint / laptop agent coverage — Working (macOS/Windows/Linux; macOS kernel sensor Pilot; Windows kernel driver Roadmap — unsigned, and enforcement does not depend on it) · Teams: SEC
The optional depth layer: process, network, and file monitors; the AI-tool detector (known-tool database + flagging of unknown processes talking to AI APIs); MCP-configuration verdicts (row 20); model-file scanning (row 4); DLP at the source; clipboard monitoring; patch inventory/remediation; A-BOM collection. Deployment reality, stated plainly: we know no one wants another agent. The platform is built so the agent is one deployment option, scoped to the populations where local AI tools actually appear (developer machines), not a prerequisite for the platform. Risk: local AI tools — a CLI agent installed without approval — are invisible to every browser and network control at the moment of installation.
17 · Browser surface coverage — Working (Chromium/Edge/Brave; Firefox and Safari builds exist at earlier maturity) · Teams: SEC
MV3 extension: pre-navigation URL trust-gate checks, in-browser DLP and redaction, upload control, verdict banners users can understand. Rolls out via MDM with no agent. Honest scope: a dedicated browser-security product will carry deeper in-browser features than a seven-surface platform carries in the browser alone. For an organisation that already owns a browser-DLP plugin, this surface is optional rather than the pitch. Risk: browser-borne AI usage and data entry — for orgs that don't already have a browser DLP control.
18 · Developer tools / IDE surface — Pilot · Teams: ENG, SEC
Extensions for VS Code, Visual Studio, Cursor, and Kiro, plus hooks for Claude Code — policy checks and DLP where AI-assisted coding actually happens, including prompt-submit interception. Use case: a developer's AI assistant is about to send a file containing credentials as context; it's redacted at the IDE. Risk: source code and secrets flowing to AI services through developer tools that never touch a browser.
19 · AI traffic gateway (network layer) — Working (proxy + router); firewall/EDR telemetry fusion in active development · Teams: SEC
Three network-layer options, in increasing depth: (a) a containerized transparent/explicit proxy that intercepts AI traffic and enforces policy inline; (b) an AI provider router — one gateway to 8 providers with a credential vault, request normalization, and cost tracking — which can sit behind your existing AI gateway rather than replacing it (your gateway makes one REST call per request for a verdict); (c) in active development now: consuming the telemetry your existing next-generation firewall and EDR already produce, correlating it into named findings, and pushing enforcement back through those same tools (dynamic block lists your firewall consumes natively, EDR containment) — AI-specific control with zero new agents and zero traffic re-routing. Risk: AI usage that never touches a browser or an approved gateway.
Part 2 · Prove, deploy and trust (20–37)¶
20 · Shadow-AI / AI-app inventory — Working on the agent; agentless path in development · Teams: SEC, RISK
Continuous inventory of AI software and usage: a signature database of known tools (desktop apps, CLIs, IDE plugins, browser extensions), detection of unknown processes connecting to AI provider APIs, MCP-server inventory (including plugin-bundled configurations — on a measured developer machine, 16 of 16 real server definitions lived in plugin trees the user-level config never mentioned), and A-BOM correlation. Findings carry severity verdicts and named users, not just an inventory row. Use case: the Codex-installed-without-approval scenario — surfaced as "unauthorized AI tool, this user, this host, this destination," not a row in an asset dump 40 minutes later. Risk: ungoverned AI is invisible until it's an incident.
21 · Code scanning + runtime protection — 9 languages — vuln scanning Working; Python RASP Working, other languages Pilot · Teams: ENG, SEC
Two distinct things, often conflated. (a) Code scanning: an SCA-style inventory of AI components across your repositories (plus endpoints and cloud), matched against vulnerability data (OSV) and prioritized by CISA KEV known-exploited status and EPSS exploit-prediction scores — so "which vulnerable AI libraries do we actually run, and which are being exploited in the wild." (b) Runtime protection (RASP): an in-process layer for your own application servers — Java, .NET, Python, Node.js, Go, Rust, Ruby, PHP, C/C++ — that sits inside the runtime, sees the AI calls and external content your app makes and receives, consults the trust gate before outbound fetches, and enforces policy in-app. Think WAF-adjacent, but inside the application, AI-aware. Use case: the portfolio-analysis agent's backend gets pre-ingestion checks and policy enforcement without changing app code. Risk: AI risk inside your applications, where network controls can't see.
22 · Robotics / embodied-AI control surface (ROS 2) — Pilot (validated on real hardware) · Teams: —
A security agent for ROS 2 robotics: topic monitoring, actuator policy enforcement, latching emergency stop, sensor-integrity checks. Validated on real hardware, and here is precisely what was and was not proven. Working on the robot: the latching emergency stop halted the actuator safely; speed-limit enforcement was verified on the wire — a 9.0 m/s command against a 2.0 m/s limit was delivered downstream as 2.0 m/s; and telemetry reached the control plane. Not completed: control-plane policy sync, because the bootstrap-token retrieval was unfinished when the test hardware was returned. So the safety layer enforced from local configuration exactly as designed; what remains unproven is remote policy distribution, not enforcement.
Why local-only enforcement is a deployment mode, not a degraded one. Most robots are not internet-connected. A safety agent that enforces limits and holds an emergency stop from local configuration — with no control plane reachable — is the operating mode a disconnected fleet actually needs, and it is the same air-gap property as 33. Remote policy sync is an enhancement for connected fleets, not a prerequisite for the control.
Included for one reason: it exists and it was validated on hardware. Skip it unless embodied AI is in scope.
23 · AI-agent identity, delegation chains, revocation — Working · Teams: SEC, AI
Non-human AI agents become first-class identities: registered with declared capabilities and rate limits, issued short-lived scoped JWTs, attestable via SPIFFE/SPIRE for workloads, with agent-to-agent delegation chains and instant token revocation. Use case: your customer-facing agent and every internal automation gets an identity; "which agent did this, under whose delegated authority" has an answer; a misbehaving agent is revoked in seconds. Risk: agents acting with shared, unscoped, unrevocable credentials — the service-account problem, multiplied by autonomy.
24 · Privileged-action broker (kill · isolate · patch) — Pilot · Teams: SEC
Privileged endpoint actions go through one audited, entitlement-gated broker: kill process, quarantine file, apply patch — with approval workflows, maintenance windows, and per-app auto-approve rules, every action logged before and after execution. Use case: response to an unauthorized AI tool can be automated with governance — approvals and audit, not a script someone runs. Risk: response actions that are either unaccountable or so heavyweight nobody uses them.
25 · The block tells the end user who decided, and why — Working (browser surfaces; recent) · Teams: SEC
When something is blocked or redacted, the person sees which policy fired and which engine decided — a banner/interstitial with the reason, not a mystery failure. Use case: fewer helpdesk tickets, and users learn the policy instead of learning to route around it. Risk: silent blocks teach users the tool is broken; explained blocks teach them the rule.
26 · Hash-chained, tamper-evident decision ledger — Working · Teams: RISK, SEC
Every security event and decision is HMAC-SHA256-signed and hash-chained — each entry cryptographically bound to the previous — with an integrity-verification endpoint that proves any given record hasn't been altered. Plus a directed action graph: agent → model → tool → human lineage for every AI interaction. Honest note: the audit chain's signature is HMAC-SHA256 (symmetric), not post-quantum; the PQC suite (row 32) covers key transport, signing, and corpus manifests. Use case: nine months from now, prove to an examiner exactly what the control decided on a specific date, and that nobody edited the record. Risk: logs that can be silently modified are testimony, not evidence.
27 · Per-decision evidence sealing (every allow / block) — Working · Teams: RISK
Each verdict — including allows — is stored with the evidence that produced it: input fingerprint, scores per engine, the policy that matched, redirect chains and IOCs for URLs, decision lineage. This is a different thing from logging: a log or an export is a record of activity; this is evidence bound to the control decision that produced it. Use case: an examiner asks not "do you have a policy" but "show me this decision" — and you can. Risk: compliance credit claimed on controls that can't evidence individual decisions.
28 · Real-time SIEM streaming — 6 destinations — Pilot · Teams: SEC
Native per-tenant forwarding of all findings/events to Splunk (HEC), Microsoft Sentinel, IBM QRadar, Elastic, Google SecOps, and generic Syslog/CEF — with per-connector configure/test endpoints. Your SOC keeps its single pane; CyberArmor feeds it. Use case: every AI-security finding lands in your existing Splunk/Sentinel pipelines and playbooks from day one. Risk: another console nobody watches.
29 · Mapped to 18 frameworks / 290 controls — Working (packs installable; assessment depth expanding with design partners) · Teams: RISK
One-click policy packs mapped to 18 frameworks totaling 290 controls — for financial services most relevantly FINRA Cybersecurity (12 controls), SEC Cybersecurity Disclosure (9), NYDFS 23 NYCRR 500 (15), plus SOC 2, ISO 27001, ISO/IEC 42001 (AI management), NIST CSF 2.0 / 800-53 / AI RMF, CMMC L3, HIPAA, GDPR, CCPA, PCI-DSS, CIS v8, CSA CCM, OWASP (Web+API+LLM+Agentic), SANS Top 25. Enabling a pack seeds enforceable policies, not a checklist. (Counts verified against the source repository on 2026-08-18: 18 framework modules, control entries summing to 290.) Risk: AI governance that exists in a policy PDF but not in any enforcement path.
30 · Examiner-ready compliance exports — Working · Teams: RISK
Per-framework assessment reports — scored, stored, tenant-scoped, with evidence bound to each control decision — exportable for an examiner, auditor, or internal risk review. Use case: FINRA exam prep goes from a quarter of screenshot archaeology to an export. Risk: controls that work but can't be demonstrated cost nearly as much as controls that don't work.
31 · EU AI Act evidence alignment (Art. 99 regime) — Partial by design; dedicated pack Roadmap · Teams: RISK
Straight answer: there is no dedicated EU-AI-Act pack today. What exists is the alignment that matters operationally — the ISO/IEC 42001 and NIST AI RMF packs plus the per-decision evidence ledger (rows 26–27) map onto the AI Act's record-keeping, logging, and transparency duties, which is the documentation an Art. 99 penalty conversation turns on. A dedicated pack is roadmap. This matters to any organisation shipping EU-facing AI features.
32 · Post-quantum crypto executing — ML-DSA-87 + ML-KEM-1024 — Working · Teams: SEC
NIST-standardized post-quantum algorithms running in shipped code paths — ML-KEM-1024 key encapsulation for API-key transport (AES-256-GCM payloads), ML-DSA-87 signatures (with Ed25519 fallback where liboqs is unavailable), signed detection-corpus manifests with anti-rollback and expiry. "Executing" is the operative word: in the product, not on a roadmap slide. Use case: harvest-now-decrypt-later is a real concern for a financial firm's long-lived records; CNSA 2.0 timelines are already published. Risk: re-platforming cryptography later, under deadline.
33 · Fully offline / air-gapped deployment — Working (ML models are baked into images or fetched once, then fully offline) · Teams: SEC
The entire stack — detection models included — runs with no vendor egress: models load locally, nothing phones home, deployable on an isolated network segment or a single air-gapped machine. This is repeatedly the decisive property for large brokerages, banks and any institution whose data cannot leave its own network. Use case: the AI security layer inspects your most sensitive traffic without your data ever leaving your network — including to us. Risk: an AI-security vendor that is itself a data-exfiltration path.
34 · Self-hosted + customer-cloud + hosted options — Working · Teams: SEC
Same platform, three deployment shapes: your data center (Docker Compose / Kubernetes Helm), your cloud account (Terraform), or hosted by us. No capability is hostage to one model. Use case: a large institution self-hosts everything; a smaller advisory firm takes hosted; an MSSP runs it multi-tenant. Risk: "cloud-only" is a non-starter in exactly the verticals that need this most.
35 · Multi-tenant MSSP wholesale architecture — Working (console shipped; partner program forming) · Teams: —
Tenant isolation across every service plus a dedicated MSSP console for partners managing subsets of tenants. Relevant to a direct enterprise buyer mainly as an architecture proof: strict multi-tenancy is a security property, not just a business model. Relevant to an investor as the wholesale distribution path.
36 · Enterprise SSO / MFA / multi-tenancy — Working · Teams: SEC
OIDC SSO with PKCE and just-in-time provisioning against Entra ID, Okta, Ping, and AWS IAM Identity Center; TOTP MFA (RFC 6238) with backup codes and per-tenant enforcement; and directory-identity enrichment — findings and audit events resolve to a named user, department, and group, which is what makes row 20's findings actionable. Use case: "unauthorized AI tool" arrives as a person and a department, not an IP address.
37 · Independent & vendor-neutral — structurally — a fact, not a feature · Teams: — CyberArmor is independently held and owns no adjacent platform, which is what makes the bring-your-own-stack architecture credible: we consume your firewall's telemetry, feed your SIEM, sit behind your AI gateway and coexist with your EDR because we compete with none of them. For a buyer, vendor neutrality means the product's incentive is your existing stack working together rather than being displaced.
Statuses reconciled against the CyberArmor source repository on 2026-08-19. Where a capability has a known limit it is stated in its entry rather than omitted. Questions on any capability — including "show me" — are welcome; most have a runnable demonstration.
Part 3 · Capabilities folded inside the entries above¶
These five capabilities are in the product and evidenced in the source, but were folded inside broader entries above where a reader scanning titles would not find them. They are numbered separately so nothing is double-counted.
38 · Honest coverage reporting — a failed check never reads as clean — Working · Teams: SEC, RISK
Scan responses carry scan_complete and detectors_unavailable, so a detector that could not run surfaces as an explicit finding with assessed: false rather than as silence. GET /ready reports true per-model state — loaded, failed, unavailable, or not attempted — and returns degraded rather than asserting health it has not verified. Endpoint monitors follow the same rule: an agent that cannot read a watched directory reports degraded and names the path. This is distinct from 15. Capability 15 decides what happens when a component is unreachable; this decides whether the result admits its coverage was incomplete. A tool can fail closed and still hand you a clean scan it never actually ran. Use case: your dashboard is green — this tells you whether that means "we checked and found nothing" or "we could not check." Risk: the most expensive failure in security tooling is not a missed detection, it is a missed detection reported as a pass.
39 · Ransomware and mass-deletion detection (destructive-phase file behaviour) — Pilot · Teams: SEC
Three behavioural signals over user-data directories, on by default: mass deletion (100 files in a 60-second window), mass encryption by rename (5 files renamed to known ransomware suffixes within 60 seconds), and in-place encryption (Shannon entropy ≥ 7.5 bits/byte over the first 4 KB of rewritten text, source, config and log files). Scope is each user profile's Documents, Downloads and Desktop plus a temp directory. This is destructive-phase detection — it catches the behaviour, not the binary, so it does not depend on recognising a family. Honest scope: it is a behavioural signal on user-data paths, not a full anti-ransomware product, and it does not replace your EDR. Use case: an AI coding assistant is induced to run a destructive script; the file behaviour is flagged as it happens. Risk: capability 10 detects ransomware shape in generated output; this detects the destructive phase actually executing on disk.
40 · Vulnerability scanning with exploit-based prioritisation — Working · Teams: ENG, SEC
CVE matching over the AI Bill of Materials via OSV, enriched and prioritised by CISA KEV known-exploited status and FIRST EPSS exploit-prediction scores — so the question answered is not "how many CVEs do we have" but "which vulnerable AI components do we actually run, and which are being exploited in the wild right now." Inventory spans endpoints, source repositories and cloud sources. Note: this sits inside row 21, whose title emphasises runtime protection; it is called out separately here because it is Working today and is the row an application-security team will ask about first. Risk: vulnerable AI/ML dependencies prioritised by CVSS alone waste the remediation budget on things nobody is exploiting.
41 · AI Bill of Materials (A-BOM) — Working · Teams: RISK, ENG
Component inventory of AI artifacts — models, datasets, libraries — across endpoints, source repositories and cloud sources, with provenance. It is the substrate 5, 20 and 40 all read from: the vulnerability scan matches CVEs against it, shadow-AI findings correlate to it, and supply-chain questions resolve against it. Called out separately because "what AI artifacts exist in this organisation and where did each come from" is a question examiners and internal audit ask directly, and it deserves an answer that is not buried inside three other rows. Risk: you cannot govern, patch or attest to AI components you have never inventoried.
42 · Patch remediation through the audited broker — Pilot · Teams: SEC, ENG
Endpoint patch remediation across winget, Homebrew, apt and yum/dnf, entitlement-gated, with maintenance windows, an approval workflow and per-app auto-approve rules — executed through the privileged-action broker (24) so every action is logged before and after. Use case: a vulnerable AI library flagged by 40 is remediated on the affected endpoints with approvals and an audit trail, rather than by a script someone runs by hand. Risk: knowing which component is exploitable and having no governed path to fix it.
The three questions this document is built to answer¶
For a CISO. What does it do, what does it not do, and can I prove it to an examiner? Every row carries a status, and every known limit is written into the row rather than left to discovery — see 4, 5, 10, 11, 17, 26 and 31, each of which states a boundary. Capabilities 26, 27, 29 and 30 are the evidence chain.
For a risk or compliance leader. Does the control exist in an enforcement path, or only in a policy document? Enabling a framework pack seeds enforceable policies, not a checklist (29), and every verdict — including allows — is sealed with the evidence that produced it (27).
For an investor. What is actually built, and how far past a demo is it? Every capability carries a maturity status reconciled against the source repository, and the boundaries are written in rather than omitted. The evidence, deployment and agent-identity entries (26, 27, 29, 30, 23, 24) are where the platform extends past prompt filtering.