Capabilities and secrets

A plugin declares the most it may use. Each AI node then declares the smaller set it actually uses in that step.

{
  "capabilities": {
    "skills": ["requirements-analysis", "office-docs"],
    "mcpServers": ["jira", "gitlab"],
    "secrets": ["JIRA_TOKEN"],
    "runtime": ["browser", "office"],
    "network": true
  },
  "workflow": {
    "nodes": [
      {
        "key": "analyse",
        "type": "ai",
        "config": { "prompt": "Analyse the request and write the baseline" },
        "capabilities": {
          "skills": ["requirements-analysis"],
          "mcpServers": ["jira"],
          "secrets": ["JIRA_TOKEN"],
          "runtime": ["browser"],
          "network": true
        }
      }
    ]
  }
}

A node can't ask for a capability the plugin didn't declare; the import is rejected. Always write a node's capabilities explicitly. Older plugins without them inherit the plugin-level set.

Capability fields

Field	What it controls
skills	Skills delivered to this step. Only the listed ones are sent
mcpServers	MCP servers this step may reach. The binding then approves individual tools
secrets	Logical environment variable names. Never values
runtime	What the runner must provide: files, terminal, repository, browser, office, computer
network	Whether the step may use the network

MCP tools

The node limits which MCP servers a step can reach. The organization binding then approves specific tools from the server's real tool list.

• Tools that aren't approved don't appear when the agent lists tools.
• Calling an unapproved tool directly is rejected by both the Hub and the runner.
• A plugin can't get around this through the harness's own global MCP configuration.

Each turn carries a short-lived signed ticket with a fixed call budget. The Hub limits total calls, concurrent calls and how often the tool list is read, and briefly stops calling a connection that keeps failing. Every connection sent to a runner has the same timeout and response size limits, applied before any harness sees the result.

Runtime

runtime declares facts about the runner. It is used in node-by-node simulation and to pick a runner. If no runner has the capability, the step doesn't fall back to a Hub server that lacks it.

Network

network is a declaration that reviewers see. It also tightens tool policy where the harness supports that. Organization runners can enforce stronger isolation with their own network policy.

Secrets

secrets lists logical variable names only, such as JIRA_TOKEN.

1. In the binding, an admin maps each name to a runner-env secret reference. The reference must belong to the same organization, be enabled, and have passed a health check.
2. The Hub sends the runner only "target variable name → runner source variable name".
3. The value stays on the runner. It is injected only into the current node's child process.

Secret values never appear in the plugin, the binding, run evidence or logs. Plugin definitions, inputs and setup reject passwords, tokens, private keys and API keys.

Not a sandbox

Skills and plugins are not a security sandbox. Install them only from sources you trust, and review the permission summary before you approve a version.

harness harnesses runtime runtimes 底座