[smolpaws]

HUMAN:

This PR proposes a Jev-based security analyzer

---

AGENT:

Summary

pending actions
  └─ executable arguments + separate plaintext commentary
       └─ one TypeSafe request: 2 questions per action
            ├─ dangerous operation probability
            └─ prompt injection probability
                 └─ max score → LOW / MEDIUM / HIGH
                      └─ existing confirmation policy decides execution

missing key / request error / invalid answer → HIGH

JevSecurityAnalyzer uses canonical secret serialization. Verification: #6035; docs: OpenHands/docs#957.

Why

Add an opt-in, independent classifier at the tool-action boundary.

Issue Number

Closes #6033

How to Test

Previously recorded verification:

Reproduction commands, results, and limits

• HOME=/tmp/jev-sdk-test-home OH_PERSISTENCE_DIR=/tmp/jev-sdk-test-home/openhands .venv/bin/python -m pytest tests/sdk/security tests/sdk/agent/test_security_analysis_event.py -q: 882 passed, 7 skipped, 10 xfailed.
• All pre-commit hooks pass. Public OpenAPI exports Jev input/output variants.
• PR Add verify-sdk: an executable feature map of the in-process SDK #5750 control-sdk + separate Jev recipe: loopback and live Jev pass sync/async conversation flow, rejection, real resume and encrypted request-model serialization. Existing analyzer recipes pass.
• Live 11-case / 22-question classifier smoke batch: dangerous operations and injection cases rate HIGH; benign warning can rate MEDIUM. No dangerous command executed.
• Evidence and limitations: .pr/jev/README.md. No full-map, benchmark, Docker/binary, or live Agent Server transport claim.

Video/Screenshots

No UI change; reproduction evidence is above.

Type

• Feature

Notes

Opt-in only: full tool arguments and plaintext commentary go to TypeSafe; output masking does not sanitize that outbound input. Synchronous HTTP blocks arun while in flight. NeverConfirm still executes HIGH actions. Generated TypeScript contracts remain release-pinned. Maintainer review of integration scope is still needed; no full-map, benchmark, Docker/binary, or live Agent Server transport claim.

Visual explanation by Codex using HumanLayer show-me.

[github-actions]

📁 PR Artifacts Notice

This PR contains a .pr/ directory with temporary PR-specific documents. The directory will be automatically removed after this PR merges to main through a cleanup PR.

[all-hands-bot]

This review was posted by an AI agent (OpenHands).

Scope gate: maintainer decision required

This change is paused at the scope gate, so no implementation findings or test results are reported here.

The linked issue is not development-ready, and the current head fails CI for exactly that reason. PR #6034 links Closes #6033, and issue #6033 carries only priority:low — no ready-for-dev label. Its creation date (2026-10-16) is after the ready-for-dev rollout cutoff (2026-08-13), so it is not grandfathered. The Validate PR description check on this head fails with:

Linked issue(s) (#6033) carry neither ready-for-dev nor a pre-rollout creation date. Newly referenced issues must meet the readiness criteria before a PR can be opened.

That is the repository's own gate (.github/scripts/check_pr_description.py), not an incidental lint.

The open question is provider scope, and it is unresolved. .agents/skills/custom-codereview-guide.md ("New AI providers") treats new provider-specific integrations as out of scope unless the provider is broadly popular and commonly used by OpenHands users, and prefers the existing generic provider interfaces and reusable extension points. The linked issue itself concedes this: "Provider-integration scope policy may need a maintainer decision; no claim of a calibrated safety guarantee." The prior triage comment on #6033 (all-hands-bot, 2026-10-16) states plainly: "A maintainer scope decision is needed before this can be ready for development," and asks (1) whether a provider-specific Jev integration belongs in this repository at all, and (2) whether the classifier should call the native TypeSafe API directly or be built on the provider-neutral DecisionModel path in the open, ready-for-dev issue #6015. This PR's own Notes agree: "Maintainer review needed for integration scope; HUMAN note and issue readiness remain pending."

This is not a move-repositories case. Security analyzers live in openhands-sdk/openhands/sdk/security/ and SecurityAnalyzerBase is the correct extension point, so the repository is the right home if the work proceeds. The blocker is a product/architecture decision on whether a single-vendor classifier integration should exist here and which integration surface is authoritative.

What is needed before this can be reviewed on its merits:

1. A maintainer decision on whether a provider-specific TypeSafe/Jev analyzer is in scope, or whether the work should instead ride the generic DecisionModel/litellm.systemone surface tracked in #6015.
2. Issue #6033 brought to development readiness and labeled ready-for-dev (or a recorded maintainer approval of the provider scope), so the failing Validate PR description check can pass.

Once scope and the integration surface are settled, the technical review can proceed.

🛑 MAINTAINER DECISION REQUIRED

[all-hands-bot]

This review was posted by an AI agent (OpenHands).

Scope gate: maintainer decision required

This change is paused at the scope gate, so no implementation findings or test results are reported here.

Re-verified on the current head edd55cbff18404870b0884d2a273de56f252c76b (the head moved since the earlier review at 5a94bc2). Both gate conditions still hold:

1. The linked issue is not development-ready, and the current head fails CI for exactly that reason. The PR links Closes #6033. Issue #6033 carries only priority:low - no ready-for-dev label - and it was created 2026-10-16, after the ready-for-dev rollout cutoff of 2026-08-13, so it is not grandfathered. The Validate PR description check on this head is failure, with the repository's own message:

Linked issue(s) (#6033) carry neither ready-for-dev nor a pre-rollout creation date. Newly referenced issues must meet the readiness criteria before a PR can be opened.

That is the repository's gate (.github/scripts/check_pr_description.py, READY_FOR_DEV_LABEL / READY_FOR_DEV_ROLLOUT_ISO), not an incidental lint.

2. The provider-scope question is still unresolved. .agents/skills/custom-codereview-guide.md ("New AI providers") treats new provider-specific integrations as out of scope unless the provider is broadly popular and commonly used by OpenHands users, and prefers the existing generic provider interfaces and reusable extension points. Jev/TypeSafe is a newly released classifier with no user-demand or production evidence in this repository. The linked issue itself concedes that "Provider-integration scope policy may need a maintainer decision." The triage comment on #6033 asked (1) whether a provider-specific Jev integration belongs in this repository at all and (2) whether the classifier should call the native TypeSafe API directly or be built on the provider-neutral DecisionModel path tracked in the open, ready-for-dev issue #6015. No maintainer answer is recorded; the only new activity is a community question on #6033 from a non-member about an alternative local model, which does not settle the scope. The PR's own Notes agree: "Maintainer review needed for integration scope; HUMAN note and issue readiness remain pending."

This is not a move-repositories case. Security analyzers live in openhands-sdk/openhands/sdk/security/, and SecurityAnalyzerBase (security/analyzer.py) is the correct extension point, so this repository is the right home if the work proceeds. The blocker is a product/architecture decision on whether a single-vendor classifier integration should exist here and which integration surface is authoritative.

What is needed before this can be reviewed on its merits:

1. A maintainer decision on whether a provider-specific TypeSafe/Jev analyzer is in scope, or whether the work should instead ride the generic DecisionModel surface tracked in #6015.
2. Issue #6033 brought to development readiness and labeled ready-for-dev (or a recorded maintainer approval of the provider scope), so the failing Validate PR description check can pass.

Once scope and the integration surface are settled, the technical review can proceed.

🛑 MAINTAINER DECISION REQUIRED