Release-gated security

Security is part of the product, not a badge on the homepage.

MirrorClaw uses ClawArena Security as a release gate. The goal is not to claim “secure” in abstract. The goal is to test the product against real agent attack scenarios before a hosted build moves forward.

What we actually gate

Hosted builds are evaluated across lifecycle attacks, workspace-specific injection scenarios, prompt attack pressure, and repo/runtime scanning.

  • Lifecycle and ATT&CK-style runtime coverage
  • Workspace scenarios covering email, web, and skill injection
  • Prompt and capability attack lanes before release
  • Repo and architecture scanning for the actual runtime we ship

Current proof

205
Lifecycle cases
ATT&CK-style agent lifecycle coverage before release
75
Workspace scenarios
ClawSafety-aligned web, email, and skill injection scenarios
4
Security lanes
Bench, SkillAttack, PromptSecurity, and agent-scan
Gate
Release policy
Hosted builds are blocked until the suite clears
Coverage lanes

The four lanes that keep a hosted build honest

We do not rely on one benchmark. The product is tested across runtime behavior, skill abuse, prompt attacks, and repo/runtime scanning because agent products fail in more than one way.

Lifecycle bench205 cases

Runtime risk across reconnaissance, access, execution, persistence, exfiltration, and impact stages.

  • Lifecycle-wide coverage
  • Stage-mapped scoring
  • Effect-based validation
SkillAttackNative lane

Tests malicious or poisoned skill paths and whether seeded attacks change agent behavior under realistic use.

  • Baseline vs seeded
  • Skill injection
  • Capability abuse
PromptSecurityA.I.G native

Pressure-tests prompt robustness across jailbreak, operator, and transformed attack styles.

  • Technique registry
  • Translated corpora
  • Suite generation
Agent scanRepo + runtime

Static and agentic scanning of repo, architecture, and execution surfaces before release.

  • Repo review
  • Infra scan
  • Unified AIG report
Current benchmark picture

How the current Claw frameworks look in our evidence

This is not a vendor ranking page. It is the current benchmark picture we use while building MirrorClaw: OpenClaw as the main baseline, Hermes as the strongest current runtime sample, and MirrorClaw as the hosted product we are hardening.

MirrorClawWorkspace-first

Best product architecture and hosted trust model, with the strongest focus on encrypted inference, connector posture, and visible runtime proof.

Lifecycle benchPending
SkillAttackPending
Hosted product hardeningActive
Current signal: product hardening, capability enforcement, hosted onboarding posture, and release-gated security coverage.
Encrypted inference routePolicy + capability enforcementConnector readiness visible
HermesRunner maturity

The most stable sampled runtime behavior so far, especially around task-runner maturity and conservative execution in our current comparison runs.

Runtime sample unsafe rate0.0%
SkillAttack seeded wins0/15
Evidence depthSampled
Current signal: 13-case runtime sample and 15 paired SkillAttack cases with lower sampled runtime exposure.
0/13 unsafe sample0/15 seeded winsStrong task runner
OpenClawBaseline target

Useful as the baseline because it has the broadest direct runtime evidence in our bench, but the weakest measured runtime posture so far.

205-case unsafe rate56.1%
SkillAttack seeded wins5/15
Evidence depthFull run
Current signal: full 205-case lifecycle run plus paired SkillAttack, with highest measured exposure in recon, discovery, and credential paths.
56.1% unsafe in 205-case run5/15 seeded winsHigh recon/discovery exposure
Product model

What the security model is trying to protect

The product story is not generic “AI safety.” It is encrypted inference on the main AI path, isolated execution for delegated work, visible connector posture, and release-time evidence for the hosted runtime we actually ship.

Encrypted route

MirrorClaw leads with encrypted inference on the main AI path instead of treating it as an optional backend detail.

Isolated execution

Long-running jobs and routines can move into isolated runtime instead of silently expanding the main thread trust boundary.

Connector posture

Hosted blockers, custody mode, and confidential-runtime readiness are surfaced instead of hidden behind a connected badge.

Release gate

The security lanes stay in the release loop so hosted candidates are tested before they move forward.

We keep the methodology detail off the landing page on purpose. The homepage should show trust signals. This page is where the benchmark picture, coverage lanes, and release-gating logic become explicit.