Skip to content

[FEATURE] Add an agent-native Strix runtime using skills and MCP #698

Description

@kaddour-youcef

Problem

Strix currently owns both its security-testing capabilities and its model runtime. Users must configure a separate LLM provider and API key even when they already use an authenticated coding agent such as Codex or Claude Code.

This couples Strix’s sandbox, proxy, security knowledge, reporting, model credentials, sessions, and orchestration into one runtime.

Proposal

Add an experimental agent-native runtime that separates reasoning from Strix’s security capabilities:

  • Codex, Claude Code, or another coding agent performs all LLM reasoning through its existing authenticated runtime.
  • A portable strix-security skill defines the assessment workflow, scope rules, validation requirements, and reporting quality bar.
  • A local strix-mcp server exposes Strix’s sandbox, Caido proxy, security knowledge, findings, and report lifecycle.
  • Strix does not require or call a model-provider API in this mode.
  • The existing CLI remains usable:
strix --agent codex --target ./app
strix --agent claude --target ./app

The legacy provider-backed runtime should remain available during evaluation.

Initial proof-of-concept scope

The first implementation should provide:

  • Runtime selection through --agent auto|codex|claude|legacy
  • Ephemeral MCP configuration when launching Codex or Claude Code
  • A separately installable portable skill
  • Target initialization and scope preservation
  • Local directories, repositories, URLs, domains, IPs, and combined targets
  • Quick, standard, and deep scan modes
  • Full and diff-based source scope
  • Docker sandbox command execution
  • Caido request inspection, replay, sitemap, and scope management
  • On-demand loading of existing Strix security knowledge
  • Model-free vulnerability creation and deduplication
  • Existing Markdown, JSON, CSV, and SARIF artifacts
  • Finish, stop, cleanup, and report-state resume operations
  • Packaging and installation helpers
  • Unit tests and detailed architecture documentation

Important status

This should initially be treated as a skeleton and proof of concept, not production-ready parity with the existing Strix runtime.

The proof of concept is intended to validate the architecture and establish stable boundaries between:

  1. host-agent reasoning and orchestration;
  2. Strix security execution and persistence.

Known limitations to address

The initial version may not include:

  • Persisted Codex or Claude Code conversation history
  • Full AgentCoordinator and subagent graph parity
  • Legacy TUI and live progress parity
  • Host-agent token and cost accounting
  • Background command sessions or stdin streaming
  • Semantic model-based deduplication
  • Legacy Perplexity search
  • Built-in adapters for coding agents other than Codex and Claude Code
  • Cross-platform validation
  • Recovery for abruptly terminated MCP processes
  • Complete Docker-backed end-to-end coverage

Acceptance criteria for the proof of concept

  • Strix can launch Codex and Claude Code using the existing CLI.
  • Coding-agent mode requires no model API key from Strix.
  • The MCP process does not invoke a model provider.
  • The portable skill can be installed independently.
  • MCP initialization and tool discovery succeed.
  • Existing target and report primitives are reused.
  • Verified findings can be persisted with CVSS, PoC, remediation, and code locations.
  • Reports and SARIF are generated in the normal run directory.
  • Legacy mode remains available.
  • Unit tests and required quality checks pass.
  • Documentation clearly explains the architecture and proof-of-concept limitations.

Follow-up direction

If the proof of concept is accepted, follow-up work should focus on:

  1. a shared runtime abstraction for legacy and MCP orchestration;
  2. background process and stdin support;
  3. host-session persistence and resume semantics;
  4. semantic deduplication without hidden Strix model calls;
  5. structured progress and observability;
  6. additional coding-agent adapters;
  7. Docker-backed end-to-end tests;
  8. security threat modeling and production hardening.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions