Poxek Research · ai-soc
Context should come before SOC autonomy
Why AI-assisted SOC work should begin with evidence reconstruction and accountable analyst decisions.
The bottleneck is often reconstruction
Security operations teams do not need an AI system to declare that an alert is important. They need a defensible way to learn what the alert means in their environment. A senior analyst commonly starts with fragments: a detection record, identity activity, endpoint telemetry, cloud events, asset ownership, prior cases, and perhaps a partially documented exception. The labour is not only collecting records. It is checking whether those records describe the same entity, the same time window, and a plausible sequence of activity.
That reconstruction work is a good target for bounded automation. It is repetitive, often follows established investigation steps, and produces artifacts that can be reviewed. It is also different from making an incident decision. The distinction matters because a fluent summary can conceal missing telemetry, an incorrect join between identities, or a weak inference about cause. Moving quickly from a generated narrative to an autonomous action turns those errors into operational risk.
NIST's Cybersecurity Framework 2.0 frames cybersecurity as risk management rather than a prescribed tool sequence. Its functions include Govern, Identify, Protect, Detect, Respond, and Recover. That structure is useful for SOC design: detection and response work inside decisions about assets, ownership, acceptable risk, and authority. An AI workflow that sees only an alert stream cannot reliably supply those decisions from language alone.
What context means in an investigation
Context is not a longer alert description. It is a set of traceable relationships that lets an analyst test a claim. For a suspicious sign-in, that may include the observed account and source, authentication method, conditional-access result, device state, resource accessed, historical activity, and whether the account belongs to a privileged or business-critical role. For an endpoint alert, it may include the process tree, command line, file and network observations, host role, user session, and nearby events.
The important property is provenance. A handoff should distinguish an observed fact from an enrichment result and from an analyst hypothesis. “The account signed in from this address at this time” is an observation with a source. “The address appears in a threat-intelligence feed” is external enrichment with its own timestamp and confidence limits. “The activity may represent credential abuse” is a hypothesis that needs supporting and contradicting evidence.
This separation makes the material useful when the case moves from L1 or L2 to L3 or L4. The receiving analyst should be able to open the underlying evidence, see which checks ran, and understand what was not available. A system that simply presents a conclusion makes review slower when it matters most: the senior analyst must reconstruct the reconstruction.
NIST SP 800-92 remains clear on a foundational point: effective log management is an enterprise process, not a feature added after an incident. Logs must be collected, retained, protected, and made usable. AI cannot restore an event that was never captured, establish a trustworthy timestamp from inconsistent clocks, or infer ownership from an unmaintained asset record. Improving the inputs is therefore part of any AI SOC program, not a prerequisite someone else must solve later.
The case for bounded L1 and L2 assistance
The most credible early use of AI in a SOC is assistance around a constrained case workflow. A workflow can receive an event, normalize its identifiers, request approved enrichments, assemble related evidence, run a defined checklist, and prepare a case narrative. The output can then propose routing or ask for review. Each step can be logged as a tool action, not hidden inside a paragraph.
This scope is deliberately narrower than “autonomous SOC.” It does not require a model to decide that a business service can be isolated, an account can be disabled, or an incident can be closed. It does not turn a confidence score into authorization. It helps analysts spend less time copying identifiers between systems and more time evaluating the evidence and the business consequences.
MITRE ATT&CK provides a useful shared vocabulary for that work because it records adversary tactics and techniques based on real-world observations. It can guide investigation prompts and case structure: which observations would support or weaken a technique hypothesis, what related telemetry is relevant, and what follow-up questions remain. ATT&CK should not be used as a lookup table that proves adversary behavior. A technique label is an analytic aid; the case still needs evidence from the environment under investigation.
Bounded workflows also make failure visible. If an enrichment API returns no result, the case should say so. If an asset owner is unknown, that should become an explicit gap rather than an invented team name. If a model cannot resolve whether two usernames refer to the same principal, it should preserve both possibilities. Good operational automation produces a shorter path to uncertainty as well as a shorter path to a finding.
Accountability is a system boundary
NIST SP 800-61 Rev. 3 connects incident response to the broader activities of CSF 2.0 and emphasizes preparation, detection, response, recovery, and continuous improvement. The implication for AI-assisted operations is practical: a case handoff belongs in an operating model with named owners, escalation criteria, evidence retention, and review of errors. It cannot be evaluated only by whether a model produces plausible text.
Poxek AI SOC uses human-supervised automation for repetitive L1/L2 context and triage work, with evidence-aware handoffs for L3/L4 review. The product is in Private Preview. It is not presented as a replacement for incident commanders, detection engineers, or senior analysts, and it does not promise that every case can be resolved from available telemetry.
Teams assessing this approach should ask concrete questions. Which data sources are available and trustworthy? Which enrichment steps are allowed? What decisions remain human-only? How are missing data and model uncertainty shown to the reviewer? Can a senior analyst reproduce the important parts of the case without trusting the generated prose? The answers describe the safety and usefulness of an AI SOC more accurately than a claim of autonomy.
Build the handoff before the autopilot
The practical sequence is to define a reviewable case contract before adding more automation. Start with the fields a senior analyst needs: timeline, entities, source links, checks performed, findings, gaps, confidence rationale, and recommended next owner. Then automate the stable, low-risk collection and normalization steps that populate those fields. Finally, measure the workflow with sampled human review and improve the underlying data and playbooks when recurring gaps appear.
That sequence keeps the goal clear. AI can make a SOC more useful by reducing repetitive reconstruction while leaving judgment, authorization, and accountability where they belong. A system that prepares evidence well is already valuable. It does not need to pretend that the people responsible for difficult decisions have become optional.