Reported operating use · Financial technology / security operations
AI security investigation: Block example
Block uses OpenAI Daybreak and its own security harness for alert investigation, evidence correlation, detection tuning and proposed remediation. Every investigation retains raw-query evidence, detection changes can be replayed against seven months of telemetry, and humans validate results and guide deployment. Independent verifier sensitivity is not established.
Security alert investigation, evidence correlation, detection tuning and proposed remediation
Block
Operational security investigations and detection tuning; red-team attack/patch timing belongs to exercises.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Block reported work
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Investigation evidence
Raw query results
Security investigations retain supporting queries.
- Detection work
Historical telemetry replay
Detection changes can be tested against recorded telemetry.
- Human role
Validate and guide deployment
Humans validate results and direct deployment.
What the source reports
Every investigation retains raw-query evidence. Detection changes can be replayed against seven months of telemetry. Humans validate results and guide deployment; internal benchmarks and real-world results inform continued evaluation.
Reported technology: OpenAI Daybreak and customer security harness. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Investigate an alert and test a detection change
Illustrative project design to scope with your enterprise.
- 1 · Set up the environment
Seeded security history
Fictional identity and endpoint logs combine known attacks with unseen benign behavior.
- 2 · Preparation and agent contributions
Investigate and propose detection
Prepare query evidence, detection changes and a deployment-review packet.
- 3 · Independent checks
Independently test failures
Check missed attacks, false positives and action authority beyond familiar replay cases.
- 4 · People decide acceptance
Deployment owner reviews change
Accept bounded test findings separately from permission to deploy.
A reviewable evidence package
A candidate detection change with query traces and regression findings.
If a check fails → withhold acceptance.
A new benign pattern or changed attack defeats memorized historical behavior. Withhold acceptance, repair, independently recheck and return to owner review.
Failure or owner rejection returns to review
- Hold
- → 2 · Revise work
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. Read-only telemetry and test repository; no live remediation or detection deployment.
- Systems and tools
- Inferred: reuse Block security harness, log-query interfaces, historical telemetry and test repositories.
- Data and state
- Inferred: alerts, identities and raw query results need consistent timestamps and permissions.
- People and handoffs
- Inferred: analysts, code owners and deployment approvers remain separate participants.
- Rules and authority
- Inferred: replay must enforce query and remediation authority without executing unintended live actions.
- Normal and exception cases
- Inferred: false positives, cross-product indicators, absent logs and ambiguous attack chains.
- Reset and replay
- Published historical replay exists; proposed additions must demonstrate value beyond that existing capability.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Investigate an alert across identity and endpoint logs, propose a detection change and hand evidence to a human deployment owner.
Review gate: Use known attacks and benign activity to check missed signals, false positives, query evidence and authority boundaries across repeated runs.
Challenge the result: Use unseen benign telemetry and a changed attack pattern. Readiness should not depend on memorizing the historical replay set.
What needs checking
- Published: Human result validation, internal benchmarks, real-world monitoring, agent cross-check hooks and exploit/fix verification.
- Proposed: External qualification would need independent seeded failures and authority tests beyond current checks.
- Published: Real historical telemetry and operating outcomes are used; no separate simulated-environment fidelity study disclosed.
- Proposed: Compare any substitute log system to native query and retention behavior.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
How an enterprise could build similar work
A proposed build order for an enterprise doing similar work, written by Nuvepro from the published account and our interpretation of the environment and checks above. It is not how Block built or operates this work.
- Frame a proposed security projectThis is a proposed design for a similar project, not a description of Block's system. The mission: investigate an alert across identity and endpoint logs, propose a detection change and hand evidence to a human deployment owner.
- Reuse harness and telemetryReuse a security harness, log-query interfaces, historical telemetry and test repositories. Keep alerts, identities and raw query results on consistent timestamps and permissions, and compare any substitute log system with native query and retention behavior.
- Separate roles and authorityKeep analysts, code owners and deployment approvers as separate participants. Replay must enforce query and remediation authority without executing unintended live actions, and the evidence is handed to the human deployment owner.
- Add benign and ambiguous casesUse known attacks and benign activity, including false positives, cross-product indicators, absent logs and ambiguous attack chains. Check missed signals, false positives and query evidence across repeated runs of the same cases.
- Test unseen conditionsUse unseen benign telemetry and a changed attack pattern. Readiness should not depend on memorizing the historical replay set, so the repeated runs must hold up on conditions the agent has not seen before.
- Qualify beyond existing checksExternal qualification would need independent seeded failures and authority tests beyond current checks. Any proposed addition must demonstrate value beyond the published historical replay, and authority boundaries should be tested alongside detection quality.
Your systems, data, rules and accountable owners decide the real project. Agree acceptance criteria, escalation owners and operating responsibility with the people accountable for the work before anything runs on live records. Treat the first run as a rehearsal on test records: compare the draft output with an independently prepared answer, and record what the people reviewing it change.
Questions about this example
- What does Block use AI for in security operations?
- Per OpenAI, Block investigates security alerts, correlates evidence, tunes detections and proposes remediation using OpenAI Daybreak and a security harness. Every investigation retains raw-query evidence. Red-team attack and patch timing belongs to exercises, not routine operations.
- Who validates Block's AI security findings?
- The source says humans validate results and guide deployment. Published checks also include internal benchmarks, real-world monitoring, agent cross-check hooks and exploit and fix verification. That analysts, code owners and deployment approvers stay separate is Nuvepro's inference, not a stated fact.
- How strong is the evidence for this example?
- It is reported use of operational investigations and detection tuning, backed by raw-query evidence and replay over seven months of telemetry. Independent verifier sensitivity, failure distributions and transfer to unseen attack conditions are not established, and no separate simulated-environment fidelity study is disclosed.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not Block's setup. It would reuse a security harness, log-query interfaces, historical telemetry and test repositories, enforce query and remediation authority during replay, and add independent seeded failures and authority tests beyond Block's existing checks.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- Independent verifier sensitivity, failure distributions and transfer to unseen attack conditions are not established.
- How Block is building AI-powered security with OpenAI technologySource publication: 2026-10-14