socxen
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.
An AI SOC analyst as an agentic skill — investigates and triages Exabeam New-Scale alerts end to end, with governance gates and guardrails
socxen
an agentic SOC skill suite for Exabeam New-Scale
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 asexabeam— neither layer recognizes another name):git clone https://github.com/open-agent-ai-security/socxen.git cd socxen && ./plugin/install.sh --merge-permissionsThe flag is the consent: nothing merges by default and
-ydoesn'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.
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 procedures — soc-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 — seeCONTRIBUTING.md.
Reviews (0)
Sign in to leave a review.
Leave a reviewNo results found