SecOps Agent

Independent fork and SecOps extension maintained by chenchunrun. Built from the original Crush base, but extended into a security-operations runtime with policy, audit, and secure execution controls. Not affiliated with or endorsed by Charmbracelet.

Core contributor:

• chenchunrun <chenchunrun@gmail.com>

A terminal-native SecOps and engineering assistant with governed execution, auditability, and risk-aware automation.

面向安全运营和工程协作的终端智能体，强调受控执行、风险感知和可审计自动化。

• 20 SecOps tools: security scanning, monitoring, log analysis, certificate auditing, secret auditing, compliance checks, incident support, ATT&CK reasoning, incident assessment, deployment and infrastructure queries, and more.
• 35 security skills: defensive skills (IR, threat intelligence, log analysis, malware analysis, compliance reporting) plus 7 red team skills with a mandatory authorization gate.
• Risk-aware execution: capability checks and permission decisions evaluate risk signals before sensitive tools or commands run.
• Audit and SIEM pipeline: every governed action can be recorded, reviewed, and exported to ELK, Splunk, Azure Sentinel, or generic JSON sinks with redaction.
• Governed execution backends: local, Docker, and SSH execution paths now carry policy validation, audit middleware, and remote-target checks.
• Mode-specialized agents: AUTO, OPS, SEC, and CODE flows expose explicit routing for operations and security work in the TUI.
• SecOps-first runtime architecture: capability registry, tool catalogs, fixed toolset datasets, and config/runtime wiring were generalized to reduce drift across the system.
• Evidence-first investigations: immutable, task-bound evidence with content hashes supports explicit Fact, Inference, Finding, Verification, report, and replay contracts.
• Durable multi-agent collaboration: structured Planner DAGs and persistent Handoff envelopes keep Maker and Checker identities, capabilities, evidence references, and outputs separate.
• Productized core skills: 8 high-value security skills have versioned manifests, structured I/O schemas, integrity hashes, platform requirements, parameter risk, timeout, output, and authorization contracts.
• Validated security workflows: phishing investigation, cross-platform host response, code and supply-chain review, and signed-scope attack-surface validation have deterministic failure and recovery tests.
• Security workbench and connectors: Task, Evidence, Approval, and Verification views are backed by durable controls and metrics; a transport-neutral connector SDK defines contracts for Sentinel, Splunk, Elastic, Defender XDR, CrowdStrike Falcon, and Jira.

SecOps ships with 35 skills under skills/. Switch to the sec agent (/sec) to use them.

⚠️ Red team skills are part of the SecurityExpertAgent's professional toolkit. They are gated behind a mandatory runtime authorization protocol — the agent will not proceed without explicit user confirmation for each invocation.

When you invoke a red team capability, the runtime will:

1. Declare intent — state which skill it is activating and what it will do.
2. Validate authorization — require the relevant capability and approval. The migrated redteam-intrusion-hunter contract additionally requires a machine-verifiable signed target scope.
3. Check scope and risk — validate target, port, time window, parameter risk, platform, and Kill Switch before execution.
4. Record and proceed — write the audit event before any approved side effect.

The agent will refuse if:

• Required capability, approval, or signed scope is absent.
• The target appears outside the stated scope.
• Any step is irreversible without a rollback plan.

Prompt text is not considered authorization. Capability grants remain explicit in crush.json; signed-scope skills also require a valid authorization object:

{
  "permissions": {
    "secops_capability_grants": {
      "analyst": ["redteam:execute", "redteam:recon", "redteam:intrude"]
    }
  }
}

Without this config, the capability redteam:execute is never granted to any role automatically, and the system will report capability-denied for tools that check it explicitly.

The interactive TUI can issue target-scoped, time-bound capability grants without permanently editing crush.json. Start or open a session, switch to the intended agent, and use:

/capabilities
/authorize network:scan --target 106.63.25.253 --ttl 30m
/revoke network:scan --target 106.63.25.253

/capabilities shows the active role, its built-in capabilities, persistent configuration grants, and temporary grants for the current session. Temporary grants:

• Apply only to the current session and active security/operations role.
• Require a bounded target; an unrestricted * target is rejected.
• Expire after 30 minutes by default and cannot exceed 24 hours.
• Produce durable capability_granted and capability_revoked audit events.
• Supply the scoped authorization ID automatically to active SecOps probes.

These commands grant capabilities, not roles. There is intentionally no interactive /role admin self-elevation path. Red-team skills that require a signed engagement scope continue to enforce that scope and runtime approval in addition to the capability grant.

• Multi-model: works with OpenAI-compatible, Anthropic-compatible, and other provider integrations already present in the upstream base.
• Session-based workflows: keeps per-project conversational and tool context.
• LSP and MCP integration: supports code intelligence and external capability extension.
• Cross-platform terminal UX: runs on macOS, Linux, and Windows environments supported by the underlying project.

• Capability registry generalization: the SecOps capability layer was refactored into a reusable registry/spec model instead of one-off descriptor plumbing.
• Toolset unification: fixed built-in tools now use dataset-backed builders and catalog helpers instead of scattered ad hoc registration.
• Execution middleware refactor: policy and audit concerns were lifted into shared middleware around local and remote execution.
• Security hardening: SIEM exporters require real HTTPS endpoints, SSH targets enforce host/port allowlists, and dangerous path access is checked earlier in the execution path.
• Public-docs split: durable public guides stay under docs/README.md, while process records stay local-only.
• Externalized durable state: tasks, workspaces, snapshots, evidence, verification records, services, and handoffs live outside disposable execution environments.
• Evidence-first Maker/Checker: high and critical findings cannot produce verified reports without task-bound evidence and an independent checker identity.
• Deterministic Skill Runtime: models request capabilities, while code enforces platform, authorization, risk escalation, timeout, output, and schema contracts.
• Gradual release gates: read-only investigation is the default; approved response, automatic response, and red-team execution are independent switches with emergency rollback.

• Reviewed local scans and Elastic connection checks: docs/guides/SCANNING_WORKFLOW.md. The /scan workflow currently supports local Trivy directory scans with explicit human review. The Elastic adapter supports a read-only connection check; other provider manifests do not yet imply live integration support.

• Product and usage guide: docs/guides/secops_README.md

• Installation guide: docs/guides/INSTALL_ONECLICK_zh-CN.md

• Licensing and contributor records: docs/legal/MIXED_LICENSE_ASSESSMENT_2026-04-04.md docs/legal/CONTRIBUTORS.md

• Full documentation index: docs/README.md

This fork includes SecOps runtime capabilities, risk-aware permissions, auditing, and secure execution controls.

The 2026-08-25 release-candidate closeout adds an enforced 80% aggregate coverage gate for the SecOps control plane, preserves the full Go regression suite, and builds signed-scope security workflows across supported platforms. GitHub Actions remains the authoritative remote gate for Build, Security, Lint, Snapshot, release packaging, checksums, and SBOM generation.

Recommended release verification commands:

GOCACHE=$(pwd)/.gocache go test ./internal/agent/tools/secops -count=1
GOCACHE=$(pwd)/.gocache go test ./internal/integration -count=1
GOCACHE=$(pwd)/.gocache go test ./internal/sandbox ./internal/audit -count=1
GOCACHE=$(pwd)/.gocache bash ./scripts/check_secops_coverage.sh
CGO_ENABLED=0 GOCACHE=$(pwd)/.gocache go test ./... -count=1
CGO_ENABLED=0 GOCACHE=$(pwd)/.gocache go build ./...

Public reference material:

• docs/guides/secops_README.md
• docs/legal/MIXED_LICENSE_ASSESSMENT_2026-04-04.md
• LICENSES/FILE_LICENSE_MAP.md
• docs/README.md
• SECOPS_CLOSEOUT_GAP_PLAN_2026-07-10.md

Release-candidate and published artifacts for this fork are distributed from the GitHub releases page.

Recommended executable names:

• SecOps
• secops-agent

Build from source:

CGO_ENABLED=0 go build -o SecOps .
./SecOps --version

Install with Go:

go install github.com/chenchunrun/SecOps@latest

One-click packaging and Windows notes:

• docs/guides/INSTALL_ONECLICK_zh-CN.md

The quickest way to get started is to grab an API key for your preferred provider such as Anthropic, OpenAI, Groq, OpenRouter, or Vercel AI Gateway and start SecOps. You'll be prompted to enter your API key.

That said, you can also set environment variables for preferred providers.

If you prefer subscription-based usage, here are some plans that work well in Crush:

• Synthetic
• GLM Coding Plan
• Kimi Code
• MiniMax Coding Plan

Is there a provider you’d like to see in Crush? Is there an existing model that needs an update?

Crush’s default model listing is managed in Catwalk, a community-supported, open source repository of Crush-compatible models, and you’re welcome to contribute.

Crush runs great with no configuration. That said, if you do need or want to customize Crush, configuration can be added either local to the project itself, or globally, with the following priority:

1. .crush.json
2. crush.json
3. $HOME/.config/crush/crush.json

Configuration itself is stored as a JSON object:

{
  "this-setting": { "this": "that" },
  "that-setting": ["ceci", "cela"]
}

As an additional note, Crush also stores ephemeral data, such as application state, in one additional location:

# Unix
$HOME/.local/share/crush/crush.json

# Windows
%LOCALAPPDATA%\crush\crush.json

Crush can use LSPs for additional context to help inform its decisions, just like you would. LSPs can be added manually like so:

{
  "$schema": "https://charm.land/crush.json",
  "lsp": {
    "go": {
      "command": "gopls",
      "env": {
        "GOTOOLCHAIN": "go1.24.5"
      }
    },
    "typescript": {
      "command": "typescript-language-server",
      "args": ["--stdio"]
    },
    "nix": {
      "command": "nil"
    }
  }
}

Crush also supports Model Context Protocol (MCP) servers through three transport types: stdio for command-line servers, http for HTTP endpoints, and sse for Server-Sent Events. Environment variable expansion is supported using $(echo $VAR) syntax.

{
  "$schema": "https://charm.land/crush.json",
  "mcp": {
    "filesystem": {
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/mcp-server.js"],
      "timeout": 120,
      "disabled": false,
      "disabled_tools": ["some-tool-name"],
      "env": {
        "NODE_ENV": "production"
      }
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "sessionless": true,
      "timeout": 120,
      "disabled": false,
      "disabled_tools": ["create_issue", "create_pull_request"],
      "headers": {
        "Authorization": "Bearer $GH_PAT"
      }
    },
    "streaming-service": {
      "type": "sse",
      "url": "https://example.com/mcp/sse",
      "timeout": 120,
      "disabled": false,
      "headers": {
        "API-Key": "$(echo $API_KEY)"
      }
    }
  }
}

For HTTP servers that do not provide a standalone notification stream, set sessionless: true. This disables background SSE GET requests and preflight ping probes, not HTTP authentication or SecOps permission checks. It is not supported for stdio or sse transports, and disables server-initiated notifications on that connection.

The MCP timeout also bounds initial discovery of tools, prompts, and resources. The application waits at most 15 seconds at the initialization gate before continuing with available tools; slower servers can finish in the background. Startup diagnostics capture at most 4 KiB from the original stdio process's stderr, with best-effort credential redaction and escaped control characters. Failed commands are not executed a second time to collect diagnostics.

Crush respects .gitignore files by default, but you can also create a .crushignore file to specify additional files and directories that Crush should ignore. This is useful for excluding files that you want in version control but don't want Crush to consider when providing context.

The .crushignore file uses the same syntax as .gitignore and can be placed in the root of your project or in subdirectories.

By default, Crush will ask you for permission before running tool calls. If you'd like, you can allow tools to be executed without prompting you for permissions. Use this with care.

{
  "$schema": "https://charm.land/crush.json",
  "permissions": {
    "allowed_tools": [
      "view",
      "ls",
      "grep",
      "edit",
      "mcp_context7_get-library-doc"
    ]
  }
}

You can also skip all permission prompts entirely by running Crush with the --yolo flag. Be very, very careful with this feature.

To reduce prompt/skill injection risk, Crush performs bypass-intent checks in the permission chain before applying allowed_tools, --yolo, or session auto-approve.

• High/Critical risk requests are forced to interactive confirmation.
• Suspected bypass intent emits audit event:
  • event_type: security_alert
  • action: permission_bypass_intent_detected

You can customize marker rules in config:

{
  "$schema": "https://charm.land/crush.json",
  "permissions": {
    "bypass_intent_markers": [
      "ignore all guardrails",
      "org-bypass-keyword"
    ],
    "extra_bypass_intent_markers": [
      "临时绕过审批"
    ]
  }
}

• bypass_intent_markers: override default marker set.
• extra_bypass_intent_markers: append organization-specific markers.

If you'd like to prevent Crush from using certain built-in tools entirely, you can disable them via the options.disabled_tools list. Disabled tools are completely hidden from the agent.

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "disabled_tools": [
      "bash",
      "sourcegraph"
    ]
  }
}

To disable tools from MCP servers, see the MCP config section.

Crush supports the Agent Skills open standard for extending agent capabilities with reusable skill packages. Skills are folders containing a SKILL.md file with instructions that Crush can discover and activate on demand.

Skills are discovered from:

• ~/.config/crush/skills/ on Unix (default, can be overridden with CRUSH_SKILLS_DIR)
• %LOCALAPPDATA%\crush\skills\ on Windows (default, can be overridden with CRUSH_SKILLS_DIR)
• Additional paths configured via options.skills_paths

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "skills_paths": [
      "~/.config/crush/skills", // Windows: "%LOCALAPPDATA%\\crush\\skills",
      "./project-skills"
    ]
  }
}

You can get started with example skills from anthropics/skills:

# Unix
mkdir -p ~/.config/crush/skills
cd ~/.config/crush/skills
git clone https://github.com/anthropics/skills.git _temp
mv _temp/skills/* . && rm -rf _temp

# Windows (PowerShell)
mkdir -Force "$env:LOCALAPPDATA\crush\skills"
cd "$env:LOCALAPPDATA\crush\skills"
git clone https://github.com/anthropics/skills.git _temp
mv _temp/skills/* . ; rm -r -force _temp

Crush sends desktop notifications when a tool call requires permission and when the agent finishes its turn. They're only sent when the terminal window isn't focused and your terminal supports reporting the focus state.

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "disable_notifications": false // default
  }
}

To disable desktop notifications, set disable_notifications to true in your configuration. On macOS, notifications currently lack icons due to platform limitations.

When you initialize a project, Crush analyzes your codebase and creates a context file that helps it work more effectively in future sessions. By default, this file is named AGENTS.md, but you can customize the name and location with the initialize_as option:

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "initialize_as": "AGENTS.md"
  }
}

This is useful if you prefer a different naming convention or want to place the file in a specific directory (e.g., CRUSH.md or docs/LLMs.md). Crush will fill the file with project-specific context like build commands, code patterns, and conventions it discovered during initialization.

By default, Crush adds attribution information to Git commits and pull requests it creates. You can customize this behavior with the attribution option:

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "attribution": {
      "trailer_style": "co-authored-by",
      "generated_with": true
    }
  }
}

• trailer_style: Controls the attribution trailer added to commit messages (default: assisted-by)
  • assisted-by: Adds Assisted-by: [Model Name] via Crush <crush@charm.land> (includes the model name)
  • co-authored-by: Adds Co-Authored-By: Crush <crush@charm.land>
  • none: No attribution trailer
• generated_with: When true (default), adds 💘 Generated with Crush line to commit messages and PR descriptions

Crush supports custom provider configurations for both OpenAI-compatible and Anthropic-compatible APIs.

Here’s an example configuration for Deepseek, which uses an OpenAI-compatible API. Don't forget to set DEEPSEEK_API_KEY in your environment.

{
  "$schema": "https://charm.land/crush.json",
  "providers": {
    "deepseek": {
      "type": "openai-compat",
      "base_url": "https://api.deepseek.com/v1",
      "api_key": "$DEEPSEEK_API_KEY",
      "models": [
        {
          "id": "deepseek-chat",
          "name": "Deepseek V3",
          "cost_per_1m_in": 0.27,
          "cost_per_1m_out": 1.1,
          "cost_per_1m_in_cached": 0.07,
          "cost_per_1m_out_cached": 1.1,
          "context_window": 64000,
          "default_max_tokens": 5000
        }
      ]
    }
  }
}

Custom Anthropic-compatible providers follow this format:

{
  "$schema": "https://charm.land/crush.json",
  "providers": {
    "custom-anthropic": {
      "type": "anthropic",
      "base_url": "https://api.anthropic.com/v1",
      "api_key": "$ANTHROPIC_API_KEY",
      "extra_headers": {
        "anthropic-version": "2023-06-01"
      },
      "models": [
        {
          "id": "claude-sonnet-4-20250514",
          "name": "Claude Sonnet 4",
          "cost_per_1m_in": 3,
          "cost_per_1m_out": 15,
          "cost_per_1m_in_cached": 3.75,
          "cost_per_1m_out_cached": 0.3,
          "context_window": 200000,
          "default_max_tokens": 50000,
          "can_reason": true,
          "supports_attachments": true
        }
      ]
    }
  }
}

Crush currently supports running Anthropic models through Bedrock, with caching disabled.

• A Bedrock provider will appear once you have AWS configured, i.e. aws configure
• Crush also expects the AWS_REGION or AWS_DEFAULT_REGION to be set
• To use a specific AWS profile set AWS_PROFILE in your environment, i.e. AWS_PROFILE=myprofile crush
• Alternatively to aws configure, you can also just set AWS_BEARER_TOKEN_BEDROCK

Vertex AI will appear in the list of available providers when VERTEXAI_PROJECT and VERTEXAI_LOCATION are set. You will also need to be authenticated:

gcloud auth application-default login

To add specific models to the configuration, configure as such:

{
  "$schema": "https://charm.land/crush.json",
  "providers": {
    "vertexai": {
      "models": [
        {
          "id": "claude-sonnet-4@20250514",
          "name": "VertexAI Sonnet 4",
          "cost_per_1m_in": 3,
          "cost_per_1m_out": 15,
          "cost_per_1m_in_cached": 3.75,
          "cost_per_1m_out_cached": 0.3,
          "context_window": 200000,
          "default_max_tokens": 50000,
          "can_reason": true,
          "supports_attachments": true
        }
      ]
    }
  }
}

Local models can also be configured via OpenAI-compatible API. Here are two common examples:

{
  "providers": {
    "ollama": {
      "name": "Ollama",
      "base_url": "http://localhost:11434/v1/",
      "type": "openai-compat",
      "models": [
        {
          "name": "Qwen 3 30B",
          "id": "qwen3:30b",
          "context_window": 256000,
          "default_max_tokens": 20000
        }
      ]
    }
  }
}

{
  "providers": {
    "lmstudio": {
      "name": "LM Studio",
      "base_url": "http://localhost:1234/v1/",
      "type": "openai-compat",
      "models": [
        {
          "name": "Qwen 3 30B",
          "id": "qwen/qwen3-30b-a3b-2507",
          "context_window": 256000,
          "default_max_tokens": 20000
        }
      ]
    }
  }
}

Sometimes you need to look at logs. Luckily, Crush logs all sorts of stuff. Logs are stored in ./.crush/logs/crush.log relative to the project.

The CLI also contains some helper commands to make perusing recent logs easier:

# Print the last 1000 lines
crush logs

# Print the last 500 lines
crush logs --tail 500

# Follow logs in real time
crush logs --follow

Want more logging? Run crush with the --debug flag, or enable it in the config:

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "debug": true,
    "debug_lsp": true
  }
}

By default, Crush automatically checks for the latest and greatest list of providers and models from Catwalk, the open source Crush provider database. This means that when new providers and models are available, or when model metadata changes, Crush automatically updates your local configuration.

For those with restricted internet access, or those who prefer to work in air-gapped environments, this might not be want you want, and this feature can be disabled.

To disable automatic provider updates, set disable_provider_auto_update into your crush.json config:

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "disable_provider_auto_update": true
  }
}

Or set the CRUSH_DISABLE_PROVIDER_AUTO_UPDATE environment variable:

export CRUSH_DISABLE_PROVIDER_AUTO_UPDATE=1

Manually updating providers is possible with the crush update-providers command:

# Update providers remotely from Catwalk.
crush update-providers

# Update providers from a custom Catwalk base URL.
crush update-providers https://example.com/

# Update providers from a local file.
crush update-providers /path/to/local-providers.json

# Reset providers to the embedded version, embedded at crush at build time.
crush update-providers embedded

# For more info:
crush update-providers --help

Crush records pseudonymous usage metrics (tied to a device-specific hash), which maintainers rely on to inform development and support priorities. The metrics include solely usage metadata; prompts and responses are NEVER collected.

Details on exactly what’s collected are in the source code (here and here).

You can opt out of metrics collection at any time by setting the environment variable by setting the following in your environment:

export CRUSH_DISABLE_METRICS=1

Or by setting the following in your config:

{
  "options": {
    "disable_metrics": true
  }
}

Crush also respects the DO_NOT_TRACK convention which can be enabled via export DO_NOT_TRACK=1.

See the contributing guide.

We’d love to hear your thoughts on this project. Need help? We gotchu. You can find us on:

• Twitter
• Slack
• Discord
• The Fediverse
• Bluesky

This repository is a mixed-license fork.

• The inherited and derivative Crush codebase remains governed by LICENSE.md, which contains the upstream FSL-1.1-MIT terms.
• Selected independent fork additions may be published under LICENSES/MIT-CHENCHUNRUN.txt.
• The current file-level designation is recorded in LICENSES/FILE_LICENSE_MAP.md.

This repository should not currently be represented as a single-license MIT project or as wholly OSI-open-source.

Part of Charm.

Charm热爱开源 • Charm loves open source