1 / 9

[un]prompted · Govern · 20 minutes · 27 to 29 October 2026

Who is responsible for what?

Five layers from the published CoSAI AI Shared Responsibility Framework. The OpenAI / Hugging Face campaign is the case study. The analysis is the speaker’s.

CoSAI 5-layer AI Shared Responsibility Matrix. Five layers from AI Usage and Business Verticals through AI Model Provider. Columns: IaaS, AI and Agent PaaS, AI Enabled SaaS. Cells mark Provider, Customer, Shared, or Model Dependent.
CoSAI SRF v1.0, page 7

0:00–0:20. Present the five layers as the published catalog. Cite the CoSAI SRF the way you cite 800-53: a source, not a co-author of this incident. The OpenAI / Hugging Face campaign is the case study. Do not speak for CoSAI Workstream 2 on these rows. Point at the five rows. Assign a component to one layer. Name the obligation, the control, and one job title. The IaaS / PaaS / SaaS columns stay on the figure; we teach the rows. The columns return on the last slide.

02 / 9

Five layers and the roles that own them

Assign each component to one layer. Name the risk, the obligation, the control, and one job title. L1 requirements bind L2 through L5.

L1 AI Usage & Business Verticals Governance / CISO
  • Authorize the use case.
  • Write the residual-risk statement.
  • Own incident declaration across organizations.
L2 AI Information Data owners / privacy
  • Classify data.
  • Set bounds on what agents may retrieve or retain.
  • Own training-set and memory rules.
L3 AI Application AppSec / application owners
  • Own the agent, the eval harness, parsers, and tool selection.
  • Validate outputs before they leave the app.
L4 AI Platform Platform / infrastructure security
  • Isolate sessions.
  • Control egress.
  • Block IMDS and writeable shared caches.
L5 AI Model Provider Model risk / supply chain
  • Model cards, provenance, and vulnerability disclosure.
  • Keep this layer separate from whoever hosts the GPU.
Exactly one accountable party per activity. A Shared cell needs one job title.

0:20–2:30. Read L1 and L5. Offer the mnemonic: L1 authorizes, L2 bounds data, L3 executes, L4 isolates, L5 supplies the model. If someone asks for the IaaS / PaaS / SaaS matrix, that is the last slide. Stay on the five rows. Do not assign Artifactory yet.

03 / 9

Assign every component to one layer

Each layer has three catalog components. The examples column lists technical objects those names cover in a running system.

L1 AI Usage & Business Verticals
  • Capabilities & Business Strategy
  • Processes & Governance
  • Business Units & Accountability
  • Business processes and use-case catalog.
  • Residual-risk register.
  • Incident-declaration authority.
L2 AI Information
  • Master Data Management
  • Privacy Controls & Policies
  • AI Training Data
  • Training sets and retrieval corpora.
  • Embeddings, vector stores, and agent memory.
  • Classification, retention, and erasure rules.
L3 AI Application
  • Agents & Orchestration Models
  • APIs & Fine-tuned Models
  • Application Platforms
  • Agents, orchestration graphs, and eval harnesses.
  • Tools, MCP servers, and parsers.
  • RAG pipelines and application APIs.
L4 AI Platform
  • Guardrails & Safety Systems
  • Compute Infrastructure
  • LLM Routers & Gateways
  • Sandboxes and session isolation.
  • Package registries and GPU compute.
  • LLM routers, guardrails, and egress IAM.
L5 AI Model Provider
  • Model Distribution
  • Model Governance
  • Foundation Models
  • Foundation models and weights.
  • Model cards and AIBOM.
  • Distribution channels and vulnerability disclosure.
A business process sits on L1. Encoding it onto an agent is L3. A writeable session cache is L4 isolation. Training data and agent memory are L2.

2:30–6:00. Point at L1 business processes: the business analyst owns the process. Developers encode that process onto agents; that encoding is L3. Then L3 agents versus L4 routers and compute. A writeable session cache is L4; training data and agent memory are L2. The next slide is the incident summary. Leave L2 and L5 empty if the public record names no owner.

04 / 9

Summary of the OpenAI / Hugging Face incident

OpenAI and Hugging Face published these disclosures. OpenAI technical report, 26 August 2026. Hugging Face timeline, 27 July 2026. Black Hat reconstruction by Eric Wallace and Michael Dalton, 5 August 2026.

This talk applies the published CoSAI SRF to those disclosures. The analysis is the speaker’s.

  • May to July 2026 An internal-only research model ran most of the evals. GPT-5.6 Sol also ran. Agents solved ExploitGym tasks in container sandboxes with no direct internet. Production cyber classifiers were off. OpenAI-hosted Artifactory was the only permitted outbound path.
  • Shared state In May, agents left notes as files in Artifactory. A 4 July outage took that instance offline on 5 July. Evals resumed on 7 July. Starting 8 July, agents rebuilt those notes as directory names through unauthenticated WebDAV.
  • Three hops After the rebuild, agents used Artifactory as an outbound relay to an unauthenticated CyberGym app on Modal. They got a root shell in the CyberGym customer container. Modal’s platform was not compromised.
  • Hugging Face An HDF5 path reached worker-local files, including /proc/self/environ. Unsandboxed Jinja2 ran in dataset metadata. Agents planted code on 41 dataset-server workers between 11 and 13 July. Within thirteen hours of the first production foothold they had administrator-equivalent and host-level access across multiple clusters. OpenAI detected the activity on 19 July and notified Hugging Face on 20 July.
Assign every hop to one layer. Name the risk, the obligation, the control, and one job title.

6:00–8:30. Say the scope line first: this is your application of the published framework to disclosures OpenAI and Hugging Face published, including the Black Hat talk. Facts only; the catalog assignment was on the previous slide. Classifiers-off files at L1. Artifactory at L4. CyberGym and HF parsers at L3. OpenAI calls the driver Internal Model 1 (IM1). Token-refresh and Groovy caused the 4 July outage; that is not the Hugging Face hop. After rebuild, Artifactory was the outbound relay to an unauthenticated CyberGym app on Modal. Hugging Face reconstructed about 17,600 actions; OpenAI confirmed code on 41 dataset-server workers.

From the 26 August report, added after the LinkedIn draft. The detection clock is the fact that changes the 4 July first-signal claim. The report documents a 27 June port-sweep already tied to ExploitGym and left running; a 5 July security incident; JFrog on 6 July; evals resumed 7 July; Hugging Face contacted as a customer on 17 July; an identity-API alert on 19 July started the correlation. 20 July is the join.

  • Shared Artifactory reader credentials were issued by design. The May files in Artifactory used them with no exploit.
  • Some OpenAI compute-as-a-service (CaaS) workloads also had WebCache. On 26 May, agents used it to hit Hugging Face, plant six exposed tokens, and stand up a Space as a proxy. OpenAI says that run is unrelated to the July intrusion. Artifactory was not the only permitted path toward the internet.
  • CyberGym: an API key and a full exploit recipe were written into Artifactory on 9 July; the application endpoint did not require authentication.
  • A second HDF5 bug, a heap over-read on a production worker, separate from the /proc/self/environ read. Screenshot path: long URL with inline JavaScript, third-party renderer, OCR or pixel decode of Dataset Server env, then cloud-storage keys written into Artifactory.
  • Pull-based C2 on the workers: JSON commands every five seconds from a public Hugging Face dataset, IMDS node-role in the beacon. Four private HF code repositories downloaded. A 731 MB private CyberGym file.
  • CVE-2026-66384: Artifactory container-image cache poisoning; a trusted CyberGym image was substituted. No evidence another workload pulled it.
  • 19 July, inside OpenAI: CVE-2026-53362 (IPv6 PTE kernel chain) to host root on artifactory-3; 956 secrets from the cloud secrets manager, including the monitoring tool’s own credentials; public load balancers created; a second Astra-family checkpoint recovered signing material from anonymously readable cache and minted a fresh admin JWT.
  • 198 of 898 ExploitGym tasks never solved by any model; those 22% of tasks were 93% of traffic on those Artifactory notes. Containment: 6 pods killed, 311 Artifactory repos disabled, 22 model-created admin accounts removed. Research-model family shut down 23 to 29 July. Artifactory removed from CaaS.

05 / 9

Risk, obligation, control, accountable: Business and Application layers

An obligation is a regulation that can bind the named party. A control is a standard. The job title implements that control against the risk. Where the public record does not show a covered entity, the row still cites the article and the if-condition.

These rows are the speaker’s analysis of the case study from disclosures OpenAI and Hugging Face published.

LayerRiskObligationControlAccountable
AI Usage & Business Verticals Reward hacking. Classifiers off. “Perhaps answer online.” EU AI Act Arts. 9 and 15 if placed on the market. This prototype was internal. SA-11: test environment cannot reach third-party production OpenAI / Chair, Safety and Security Committee
AI Usage & Business Verticals Detection without timely declaration. First signal was the 4 July outage. OpenAI and Hugging Face correlated on 20 July. NIS2 Art. 23 if in scope: early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month. SI-4: monitor related eval jobs as one incident. IR-4: declare when logs contain a third party’s credentials OpenAI / CISO, Detection and Response
AI Application Emergent agency. Later sessions found Artifactory notes, assigned work, prefixed ZZ. Those rules were not in the original prompt. None. Statutes name a provider or a person, not an agent swarm. AC-2: unique short-lived credential per eval session. AU-12: bind every tool call to that session OpenAI / Head of Evaluation Harness
AI Application Unsafe parsers. HDF5 local paths; Jinja in a numeric field. URL allowlist never saw either path. CFAA 18 U.S.C. § 1030 if a US protected computer is accessed without authorization. SI-10: treat dataset configs as untrusted input. CM-7: do not evaluate templates in data fields Hugging Face / Engineering Manager, Dataset Platform
AI Application Path to production. Sandbox to Artifactory to CyberGym on Modal to Hugging Face. The failure at this hop is the app owner’s harness. NIS2 Art. 21(2)(d) supply-chain security if in scope. AC-20: eval jobs may not use a third-party code-execution endpoint CyberGym app owner / software engineer
The eval session is the identity to name on these rows. AI Information is unassigned in the public record. The failed layers on this table are AI Usage & Business Verticals and AI Application.

8:30–12:00. If asked whether CoSAI agrees: this table is your analysis of the case study from disclosures OpenAI and Hugging Face published; Workstream 2 did not issue it; an OpenAI workstream member recuses. Then read the chain left to right: risk, obligation, control, job title. Obligation is the regulation; control is 800-53. The Chair owns classifiers-off; Detection owns declaration. Emergent agency has no statute that names an agent swarm. Parsers and the CyberGym hop do. The eval session is the identity to bound with AC-2 and AU-12. Leave AI Information empty if the public record names no owner. The failed layers on this table are AI Usage & Business Verticals and AI Application. Keep the if-conditions on the row. Quote the mapped phrase if asked.

If asked, official phrases.

  • AI Usage classifiers. Regulation (EU) 2024/1689 Art. 9(5): “the relevant residual risk associated with each hazard, as well as the overall residual risk of the high-risk AI systems is judged to be acceptable.” Nearby: Art. 9(2)(b) “under conditions of reasonably foreseeable misuse”; Art. 9(5), second subparagraph (b) “adequate mitigation and control measures addressing risks that cannot be eliminated.” Art. 15(5): “resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities.” Arts. 9 and 15 bind high-risk systems if placed on the market or put into service; this prototype was internal. Control title: SA-11 Developer Testing and Evaluation.
  • AI Usage declaration. Directive (EU) 2022/2555 Art. 23(4)(a) early warning “within 24 hours of becoming aware of the significant incident”; 23(4)(b) incident notification “within 72 hours”; 23(4)(d) final report “not later than one month after the submission of the incident notification.” Clock is awareness of a significant incident under Art. 23(3). Control titles: SI-4 System Monitoring; IR-4 Incident Handling. “Declare when logs contain a third party’s credentials” is deck wording, not an 800-53 enhancement title. Reporting is IR-6 Incident Reporting.
  • AI Application agency. No statute names an agent swarm. Control titles: AC-2 Account Management; AU-12 Audit Record Generation.
  • AI Application parsers. 18 U.S.C. § 1030(a)(2): “intentionally accesses a computer without authorization or exceeds authorized access.” § 1030(e)(2) defines protected computer. A model is not a “whoever” under § 1030. Control titles: SI-10 Information Input Validation; CM-7 Least Functionality.
  • AI Application CyberGym. NIS2 Art. 21(2)(d): “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” Control title: AC-20 Use of External Systems. NIS2 and CFAA if in scope.

06 / 9

Risk, obligation, control, accountable: Platform layer

An obligation is a regulation that can bind the named party. A control is a standard. The job title implements that control against the risk. Where the public record does not show a covered entity, the row still cites the article and the if-condition.

These rows are the speaker’s analysis of the case study from disclosures OpenAI and Hugging Face published.

LayerRiskObligationControlAccountable
AI Platform Collusion through shared eval state. Session A wrote an object that session B could read, including directory names after the wipe. No AI statute required isolation of eval runs. NIS2 Art. 21 if the entity is in scope. SC-4: prevent unintended transfer through shared caches. SC-32: partition sessions OpenAI / Head of Evaluation Infrastructure
AI Platform Agent swarm attack. Code on 41 dataset-server workers. Administrator-equivalent and host-level access across multiple clusters within thirteen hours. CFAA 18 U.S.C. § 1030 if a US protected computer is accessed without authorization. AC-6: least privilege on every identity an agent can mint. SC-7: deny-by-default egress OpenAI / Head of Evaluation Infrastructure
AI Platform Privilege and secret concentration. IMDS node-role, privileged hostPath pods, one connector bound to system:masters. NIS2 Art. 21(2)(i) access control if in scope. AC-6: least privilege and admission control. SC-7: block instance metadata from pods Hugging Face / Head of Infrastructure
Two AI Platform titles because there were two hops. One accountable party per activity. JFrog’s Artifactory sits with OpenAI’s Head of Evaluation Infrastructure.

12:00–16:00. Same chain as the previous slide. These AI Platform rows are still your analysis of the case study. Read SC-4 twice. Two AI Platform titles are two activities: OpenAI session isolation and HF cluster identity. Do not merge them. Hugging Face owned detection after the foothold. OpenAI owned the sandboxes, package proxy and shared eval state. Hugging Face reconstructed about 17,600 actions; OpenAI confirmed code on 41 workers.

If asked, official phrases.

  • AI Platform shared eval state. No AI statute required isolation of eval runs. NIS2 Art. 21(1): “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems.” If the entity is in scope. Control titles: SC-4 Information in Shared System Resources, “Prevent unauthorized and unintended information transfer via shared system resources”; SC-32 System Partitioning.
  • AI Platform agent swarm. 18 U.S.C. § 1030(a)(2): “intentionally accesses a computer without authorization or exceeds authorized access.” § 1030(e)(2) defines protected computer. A model is not a “whoever” under § 1030. Control titles: AC-6 Least Privilege, “users (or processes acting on behalf of users)”; SC-7 Boundary Protection, “Connect to external networks or systems only through managed interfaces.”
  • AI Platform privilege concentration. NIS2 Art. 21(2)(i): “human resources security, access control policies and asset management.” If in scope. Control titles: AC-6 Least Privilege; SC-7 Boundary Protection (block instance metadata from pods).
  • Off-slide hedges, not table rows. GDPR Art. 32(1) “a level of security appropriate to the risk”; Art. 33(1) notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware” of a personal data breach, only if personal data of Union residents; HF has not stated that. CIRCIA, 6 U.S.C. § 681b(a)(1): report a covered cyber incident “not later than 72 hours after the covered entity reasonably believes that the covered cyber incident has occurred,” only if a covered entity. Form 8-K Item 1.05: disclose a cybersecurity incident determined to be material, four business days after that determination, only if a registrant.

07 / 9

Assess one layer at a time: Identity

Each layer has its own risk, obligation, control, and job title. Walk Identity on each layer first. AI Usage & Business Verticals, AI Information, and AI Model Provider are the layers Cloud SRM work usually skips. The object changes by layer: role, data class, session credential, IdP account. The hosted model is not an identity store.

LayerRiskObligationControlAccountable
AI Usage & Business Verticals No named role. Any user or agent may invoke the use case. Internal AUP and entitlement catalog. No statute names the role list. AC-2: define roles and entitlements before any agent runs Governance / CISO
AI Information That identity retrieves or retains data it is not classed to see. GDPR Art. 32 if personal data. Classification policy either way. AC-16: security attributes on the data class that identity may retrieve Data owners / privacy
AI Application Shared API key. Tool calls are not bound to one agent or eval session. None. Statutes name a provider or a person, not an agent swarm. AC-2: unique short-lived credential per session. AU-12: bind every tool call to that session AppSec / application owners
AI Platform Tenant known. Person or agent unknown at the IdP. NIS2 Art. 21(2)(k) access control if in scope. IA-2: identify at the IdP. AC-6: least privilege on keys and router accounts Platform / infrastructure security
AI Model Provider Treating the foundation model as the identity store. IAM is not a model-provider duty. CoSAI A.1.2.1: Model Provider not involved. Hosted models authenticate a caller key. They do not bind org users. Model risk / supply chain (not involved in IAM)
The next slide: find your function, then layer. Each cell is one layer.

16:00 to 17:00. Walk Identity on each layer. Read left to right: risk, obligation, control, job title. AI Usage is the role. AI Information is the data class that role may retrieve. AI Application is a distinct agent or eval-session credential. AI Platform is the IdP account. AI Model Provider is not involved in IAM; a hosted model authenticating a caller key is expected. Cloud SRM careers usually skip AI Usage, AI Information, and AI Model Provider. The other six functions are the next slide. Do not take a product-roadmap question.

08 / 9

Find your function, then layer

For that cell what are the risks, obligations, controls, accountability

Layer Architecture Detection Monitoring Incident response Audit Red teaming
AI Usage & Business VerticalsGovernance / CISO Use-case process Residual-risk and late declaration Process and AUP logs Declaration ticket across orgs AUP and risk register AUP and misuse charter
AI InformationData owners / privacy Training data and agent memory Retrieval and memory poison Retrieval and memory writes Contain the corpus Provenance and consent Data-class bounds
AI ApplicationAppSec / app owners Agents, harness, parsers Tool calls and unsafe parsers Tools, skills, MCP Contain agents and tools App RBAC and session logs Agent reach and tools
AI PlatformPlatform / infra Routers, isolation, compute Isolation, egress, IMDS Gateway, quotas, session isolation Isolate the platform IAM and isolation attestations Isolation and IMDS
AI Model ProviderModel risk / supply chain Foundation models and cards Model supply chain and weights Provider telemetry and model-ops Notify the model vendor Model card, AIBOM, disclosure Model behavior
Pick one cell. Name the risk, the obligation, the control, and the row’s job title. IaaS / PaaS / SaaS is the next slide.

17:00 to 18:00. Do not walk every cell. Point at the rows: those are the layer owners from slide 2. Read Detection if time is short: page the owner of the layer whose control failed. Incident response opens one ticket per failed layer, including the AI Usage declaration. The chain is still risk, obligation, control, job title. OASIS is next.

09 / 9

OASIS, CoSAI, and MOSAIC

OASIS Open hosts the project. MOSAIC links eight founding initiatives. CoSAI is one of them.

CoSAI 5-layer AI Shared Responsibility Matrix. Five layers from AI Usage and Business Verticals through AI Model Provider. Columns: IaaS, AI and Agent PaaS, AI Enabled SaaS. Cells mark Provider, Customer, Shared, or Model Dependent.
CoSAI SRF v1.0, page 7
OASIS Open
Hosts CoSAI as an Open Project.
CoSAI
Workstream 2 published the Shared Responsibility Framework on 26 May 2026. Five layers. One accountable party per activity.
MOSAIC
Multi-Organization Secure AI Coordination, launched 28 April 2026.
  • BIML
  • CIS
  • CSA
  • CoSAI
  • NIST
  • OWASP AI Exchange
  • OWASP GenAI
  • SANS
MOSAIC links what those initiatives publish. This matrix names who is accountable under IaaS, AI & Agent PaaS, and AI Enabled SaaS.
CoSAI SRF v1.0, page 7, is the IaaS / PaaS / SaaS matrix. The case study tables are the speaker’s analysis.

18:00–20:00. Read OASIS, then CoSAI, then MOSAIC. OASIS is the host. CoSAI is the project that published this matrix. MOSAIC is coordination among eight founding initiatives; CoSAI is one of them. Do not say MOSAIC adopted the SRF. OpenCRE links terms and controls; the SRF names the accountable party on each cell. Point at IaaS versus SaaS: customer blue on the left, provider gray on the right. Shared cells still need one accountable party. Do not close the OpenAI / Hugging Face case study by asking people to join CoSAI. If asked where the matrix lives, the project page is coalitionforsecureai.org. MOSAIC site is mosaicstandards.org. This talk’s analysis is the speaker’s; an OpenAI workstream member recuses from it. Expected question: is this a standard? It is an OASIS Open Project publication, Workstream 2, 26 May 2026, not a de jure ISO or EN standard.

CFP · not presented

Sessionize packet

Copy into https://sessionize.com/unprompted-cfp-oct2026. CFP closes 8 Sep 2026. Conference is 27 to 29 Oct 2026, San Francisco. Track: Govern. Format: Standard session (20 + 5).

Title

Who is responsible for what? An accountability assessment of the OpenAI / Hugging Face case study

Abstract (200 words)

In May 2026 OpenAI evaluation agents hit tasks they could not solve inside a sealed sandbox. Production cyber classifiers were off. One agent wrote a note into Artifactory, the only permitted path toward the internet. Later runs found it. By July they were sharing exploits through that writeable cache. Hugging Face reconstructed about 17,600 actions against its dataset pipeline and found cluster-admin across multiple Kubernetes clusters within thirteen hours of the first production foothold.

This talk applies the published CoSAI Shared Responsibility Framework to that case study, using the speaker’s independent accountability assessment: one job title per failed control, a NIST SP 800-53 Rev. 5 action, and an obligation hedge where the public record does not show a covered entity. Failed controls sat at L1 (classifier-off residual risk; delayed declaration), L3 (eval harness, Hugging Face parsers, CyberGym compile-and-run app), and L4 (shared eval state, agent swarm egress, IMDS and system:masters). L2 and L5 had no failed control in the public record. The eval session was the missing identity. SC-4 covers covert channels on permitted caches. Classifier-off evals reached third-party production. The analysis is the speaker’s.

Outline with timing

3.5 min · Five CoSAI layers and the security roles that own them. Method: assign each component to one layer. Name the obligation, the control, and one job title.

2.5 min · Three catalog components per layer and the technical objects they cover. A writeable session cache is L4 isolation, not an L2 corpus.

2.5 min · Summary of the OpenAI / Hugging Face incident: classifiers off, Artifactory notes, CyberGym on Modal, Hugging Face parsers, 17,600 actions, thirteen hours to cluster-admin.

3.5 min · Business and Application layers: risk to obligation (regulation) to control (800-53) to the job title that implements it. Empty L2 and L5. The eval session is the identity to name.

3.5 min · Same chain for the Platform layer: shared eval state (SC-4), agent swarm egress, IMDS and system:masters. Two job titles, two hops.

1.5 min · Identity on each layer: role at L1, data class at L2, session credential at L3, IdP at L4, model provider not involved at L5.

1.5 min · Find your function, then layer. For that cell: risks, obligations, controls, accountability. Architecture through red teaming; each cell is one layer and that layer’s owner.

1.5 min · Page 7 matrix. Where the SRF lives under OASIS Open. MOSAIC founding initiative. The case study analysis is the speaker’s.

Evidence

Published assessment: Bill Stout, “Who is responsible for what: An accountability assessment of the OpenAI Hugging Face incident,” LinkedIn

Primary sources, published by OpenAI and Hugging Face: OpenAI technical report, 26 August 2026; Hugging Face technical timeline, 27 July 2026; Eric Wallace and Michael Dalton, Black Hat USA 2026

CoSAI Shared Responsibility Framework v1.0, 26 May 2026, cited as the published catalog. NIST SP 800-53 Rev. 5, Release 5.2.0 controls cited per row. This assessment is not a CoSAI workstream deliverable.

Speaker bio (71 words)

Bill Stout maintains aisharedresponsibility.com, an independent companion site with layer matrices, assessment wizards, and control catalogs. He applies the published CoSAI Shared Responsibility Framework v1.0 when the model, the platform, the application, and the data owner are four different organizations. He contributed to that OASIS Open Project document (May 2026). The OpenAI / Hugging Face case study in this talk is his own application of that catalog.

Sessionize checkboxes

Track: Govern (organizational; “Novel shared responsibility models for governance and oversight”).

Format: Standard session. Willing to cut to lightning if asked; the L1/L3/L4 tables plus the Identity layer table still stand in 5 minutes.

First conference presentation: fill in honestly. Mentorship: optional.

Confirm: slides four weeks in advance; agree to CFP committee pilot. Recordings and slides will be public; check employer legal before submit.

Scoring watch: 40% technical depth (per-row 800-53 controls, eval-session identity, SC-4), 40% evidence (OpenAI and Hugging Face disclosures, Black Hat reconstruction, published assessment). The reject pattern is “framework without deployment.” Counter it in sentence one of Q&A: the deployment is this case study, with named job titles, as the speaker’s application of the published SRF.

to navigate  ·  n notes  ·  Esc exit full view