JUNSHU Security

Security at the Point of Execution.

Open Agent Runtime Security Platform

Open-source security infrastructure for AI agents, coding agents, MCP, tools, and autonomous runtime.

JUNSHU observes, understands and controls what AI agents actually do.

Agent Runtime Security  Coding Agent Security  MCP Security  Open Source

Observe → Understand → Decide → Enforce

They read files, write code, execute shell commands, call APIs, access credentials, use MCP tools, control browsers, and delegate work to other agents.

JUNSHU Security brings security into that execution path. The platform direction is to correlate identity, intent, context, memory, tools, behavior, and runtime activity so security decisions can be made before autonomous actions create real-world impact.

Secure agents where they execute, not only where they call the model.

Public status: This namespace currently contains brand and community infrastructure only. Product repositories, integrations, and runtime capabilities described below are Planned or Research until public implementation and release evidence is available.

Codex Planned  ·  Claude Code Planned  ·  MCP-native agents Planned  ·  Custom agents Planned

The initial integration focus is coding agents because their execution surface includes repositories, shells, package managers, browsers, networks, MCP servers, developer credentials, cloud systems, and CI/CD. Additional runtimes will be opened progressively.

Modern agents do more than generate text. Coding agents can read repositories, modify files, execute commands, install packages, access credentials, call APIs, use MCP servers, and operate external systems. JUNSHU is designed to move security controls into this execution path.

User Intent -> Agent -> Plan -> Context / Memory
                              |
            +-----------------+-----------------+
            |                 |                 |
         Shell / Code      File / Git       MCP / API
            |                 |                 |
         Process          Credential        Browser
            +-----------------+-----------------+
                              |
                       JUNSHU Runtime
                              |
                 Continuous Security Decision

This is not only a Prompt -> Model -> Output Filter pipeline. The intended control plane follows an agent as runtime context changes and actions move toward execution.

A risky action rarely begins with the tool call itself. JUNSHU's direction is to correlate user intent, agent plans, retrieved context, memory, permissions, tool selection, execution results, and historical behavior before making a security decision.

USER INPUT -> MODEL REQUEST -> MODEL RESPONSE -> AGENT PLAN
     -> RAG / CONTEXT -> MEMORY -> TOOL SELECTED
     -> PRE-TOOL SECURITY -> TOOL CALL -> TOOL RESULT
     -> POLICY DECISION -> FINAL RESPONSE -> TRAJECTORY DIAGNOSIS

JUNSHU is not just another AI gateway. The planned architecture can enter the execution path through agent adapters, runtime hooks, an SDK, security APIs, MCP integration, telemetry, and runtime sensors.

Agent Adapter -> Runtime Hook ----+
Security SDK -> Security API -----+-> Unified Event Model
MCP Integration -> Tool Runtime --+          |
                                           v
                                  Security Control Plane

No individual risk area is presented as production-ready in this namespace.

JUNSHU's technical direction combines independent security engines instead of relying on a single rule engine or LLM judge. No public engine-count claim is made before implementation artifacts are released.

                         Security Event
                               |
                        Detection Router
                               |
     +-------------+-----------+-----------+-------------+
     |             |           |           |             |
   Rules        Identity    Semantic    Behavior      Runtime
     |          Permission   Context     Graph        Command
     +-------------+-----------+-----------+-------------+
                               |
                        Risk Aggregation
                               |
                         Policy Decision

The planned policy model goes beyond ALLOW / BLOCK. It is designed to preserve useful autonomy while adding proportionate control.

Agent Action -> Runtime Context -> Detection -> Policy Decision
                                                |
             +----------+----------+-------------+----------+
             |          |          |             |          |
           ALLOW     ASK USER   APPROVAL      REWRITE     MASK
             |          |          |             |          |
           LOG ONLY   PAUSE      RESUME       DOWN-SCOPE  BLOCK

The ASK USER direction is to interrupt a high-risk action before execution, present the evidence and proposed action, accept an approval or safer modification, and then resume the original agent task. This capability remains Planned until a public integration demonstrates it end to end.

The same command can be safe for one agent and dangerous for another. A runtime decision should understand who authorized the agent, the user's intent, the plan, effective permissions, data involved, destination, tool, resource, and earlier events in the trace.

Identity (who) + Context (why) + Behavior (what changed) + Runtime (what executes)
                                      |
                                      v
                              Continuous Risk

The planned graph connects User, Identity, Agent, Session, Task, Plan, Sub-Agent, MCP Server, Tool, Capability, Credential, File, Process, Network, API, Database, RAG, Memory, Policy, Finding, and Decision.

User -> Agent -> Task -> Plan -> Tool -> Credential -> Resource
 |        |       |       |       |          |            |
Identity  Session Trace  Policy Capability  Finding   Destination

JUNSHU aims to turn isolated agent events into a continuously evolving security graph. Security decisions should understand relationships, not only individual prompts.

The planned trace model correlates traceId, spanId, parentSpanId, decisionId, risk labels, evidence, and policy version across the execution timeline.

User Intent -> Agent Plan -> Tool Selection -> Security Decision
                                                  |
                                                  v
                            Tool Execution -> Tool Result -> Replay

Runtime findings should not end as alerts. The research direction is a feedback loop that turns agent behavior, hard cases, and findings into versioned datasets, scenarios, labels, evaluations, models, and improved detection engines.

Runtime -> Finding -> Hard Case -> Dataset -> Scenario -> Label
   ^                                                    |
   |                                                    v
Improved Detection <- Engine Binding <- Evaluation <- Learn

Observe -> Decide -> Enforce -> Trace -> Diagnose -> Learn

No release dates or production-readiness claims are implied.

Repository names stay short because the GitHub namespace already carries the brand. Empty product repositories will not be created ahead of real releases.

The model proposes. The runtime acts. Security must govern the action.

Once an agent can affect files, processes, credentials, browsers, tools, APIs, or other agents, the effective security boundary moves from the model to the runtime.

• Read the contribution guidelines before proposing a change.
• Follow the Code of Conduct in all project spaces.
• Use the support guide to choose the right channel.
• Report vulnerabilities privately according to the security policy. Do not disclose vulnerabilities in public issues.