socxen

agent
Security Audit
Warn
Health Warn
  • License — License: Apache-2.0
  • Description — Repository has a description
  • Active repo — Last push 0 days ago
  • Low visibility — Only 5 GitHub stars
Code Pass
  • Code scan — Scanned 12 files during light audit, no dangerous patterns found
Permissions Pass
  • Permissions — No dangerous permissions requested

No AI report is available for this listing yet.

SUMMARY

An AI SOC analyst as an agentic skill — investigates and triages Exabeam New-Scale alerts end to end, with governance gates and guardrails

README.md

socxen

an agentic SOC skill suite for Exabeam New-Scale

Project level: Incubator
CI
License: Apache-2.0

Analyst, shift lead, detection engineer.

Three skills, one governance gate. You stay in control.

socxen is an agentic SOC skill suite plus the deterministic guardrails and governance that make
it safe to point at a live tenant. Three skills — for Claude Code and OpenAI Codex, one package on
both — named for the person whose job they do:

Skill Whose work it is What it does
soc-investigate the analyst Takes one Exabeam New-Scale alert or case from first look to written verdict — pulls the underlying events, pivots on the entities it finds, weighs the activity against what is normal for them, tests a benign explanation against a malicious one, and writes up its reasoning with the evidence behind it. Then it acts: opens or updates a case, writes notes, escalates.
triage-cases the shift lead Sweeps the open queue instead of one case — clusters by attack shape, ranks by corroborated signal rather than risk score alone, and hands back a short "start here" list plus the noise worth tuning. Read-only across the sweep; it never closes in bulk.
rule-tuning the detection engineer Finds the rules quietly wasting analyst attention — noisy, not merely loud — and proposes the specific change, mapped to real Exabeam mechanics. Propose-only: the MCP's rule-write tool is denied on both hosts, and that is deliberate.

Each hands off to the others: a single case to soc-investigate, a noise cluster to rule-tuning.

Dismissing an alert or closing a case is held back by two locks, out of the box: a gate the plugin
ships and the host enforces — on Claude Code a bundled hook that asks before dismiss/close, denies
containment, and holds even under --dangerously-skip-permissions; on Codex tool-approval policy inside
the package, so Codex prompts a human for every destructive write and cancels it when nobody is present —
and the skill asking you first. Containment is recommended for a human
to perform in EDR or IAM; the plugin never executes it. No server, no database, no approval queue — the
analyst at the terminal is the human-in-the-loop.

⚠️ Pre-release software — for evaluation only. socxen is under active development. Expect
breaking changes between versions, and do not rely on it for production SOC operations or point it
at alerts whose disposition matters without a human reviewing every action.


👀 See what it produces — a worked investigation, from alert to verdict:
coordinated credential access.


Install

Claude Code

claude plugin marketplace add open-agent-ai-security/plugins
claude plugin install socxen@open-agent-ai-security

OpenAI Codex

codex plugin marketplace add open-agent-ai-security/plugins
codex plugin add socxen@open-agent-ai-security

On Codex that's the whole install — the approval gate travels inside the package, so there is no merge
step. The rest of this section is the Claude Code gate:

The gate ships ON, and the reads run without a prompt — the hook allows them. You do not need to
merge the permission pack; it is an optional second lock that does not depend on the hook (wire a
manual server as exabeam — neither layer recognizes another name):

git clone https://github.com/open-agent-ai-security/socxen.git
cd socxen && ./plugin/install.sh --merge-permissions

The flag is the consent: nothing merges by default and -y doesn't authorize it. To merge by hand
instead, and to supply your Exabeam credentials (the only other setup step), follow
the setup guide.

Then ask it to "investigate alert <id>" — or "triage the queue" / "find noisy rules" for the
other two skills.

Where your data goes

Nothing is hosted by us. socxen runs on the analyst's machine, against your Exabeam tenant, through
your own model provider under your own agreement — so residency, retention and processing terms stay
yours. The audit log is local and metadata-only.

Full detail →

How it's built

socxen is five separable layers, and keeping them separate is the point — a capable model with tool
access is not, by itself, something you can let near a SOC queue.

Layer Where What it contributes
Methodology skills/ the proceduressoc-investigate (entity pivots, baselining, competing hypotheses, an evidence bar, stopping conditions, an action matrix), triage-cases and rule-tuning, sharing one safety spine
Capability .mcp.json · .mcp.codex.json the Exabeam New-Scale MCP — SIEM search, alerts and cases, threat timelines, rule and MITRE context — bundled for each host
Authority settings.snippet.json which calls run unattended, which stop for a human, which are denied outright — enforced by the host agent, not by the model: on Claude Code a bundled hook reads these tiers (the permission pack is an optional second lock); Codex carries the same tiers inside the package, generated from this file and pinned so the two hosts' gates can't drift
Guardrails connector/ a local bridge that treats telemetry as hostile input, and writes an audit trail
Evidence security/ · evals/ red-team program and agent-behavior verification — every release is gated on both — plus the AI BOM and the SBOM, and the regression harness in evals/

Documentation

Guide What's in it
Installation & setup install, Exabeam credentials, the governance gate (start here)
Operator's guide day-to-day use once installed
Methodology how it investigates, and the bar it holds a verdict to
Security guardrails why telemetry is treated as hostile — and what this deliberately doesn't cover
Audit logging what's recorded, where it lives, how to route or disable it
Assurance how socxen is red-teamed and behavior-verified before each release

Repository layout

The distributable plugin lives in plugin/ — that subdirectory is the only thing
installed on a user's machine (via a git-subdir marketplace source). Everything else at the repo
root is build-time only and never ships: tests/ and evals/ (harnesses),
security/ (the release gates), scripts/ and .github/ (release tooling and CI).


Project sponsor

socxen is sponsored by Exabeam. Exabeam contributed the initial code and
continues to provide ongoing support and contributions to the project as part of its commitment to
security in an increasingly agentic world.


License

Apache-2.0. Contributions require a DCO sign-off — see
CONTRIBUTING.md.

Reviews (0)

No results found