An AI Agent’s Skill Is Not Its Permission

Original research: English · 中文 · Research Center

Suppose an AI Agent receives a deployment playbook. It now understands the build, test, and release sequence. The environment also exposes a terminal and file-writing tools. May it publish?

Many systems accidentally answer yes. They collapse four separate facts into one: the model knows a procedure, a tool exists, the role may call it, and this exact operation is authorized.

Think of a controlled office release. A Skill is the operating manual. A Tool is the machine that can change files or invoke an API. A role capability is the access badge. An operation policy is the work order that identifies the target and impact. Approval is the seal placed on one exact work order.

Knowing the manual, operating the machine, holding a badge, and receiving approval are different events.

Four gates, four different questions

Layer	Question	What it must not imply
Skill / playbook	How should this job be done?	That the job is permitted
Role capability	Which tools may this role call?	That every target is acceptable
Operation policy	What object and side effect are being requested?	That a human has approved it
Single-use approval	Is this exact operation allowed now?	That later or modified operations are allowed

A Tool is not permission and is not inherently safe. It is an effect-producing interface. If the gate or operating-system boundary is overprivileged, a perfectly deterministic tool can still do too much.

Figure 1. Approval grants one controlled execution attempt; it does not merge the four layers.

Why prompts cannot be the security boundary

A Skill lives in model context. It is useful for decomposing intent, choosing a workflow, and assembling parameters. But it is still probabilistic text exposed to instruction conflict and prompt injection.

Authorization must be enforced outside that context. In a Model Context Protocol (MCP) tool or local Runtime, a neutral gate should check at least:

caller identity
AND role-to-tool capability
AND canonical project root
AND target allowlist
AND operation policy
AND matching single-use approval
AND underlying OS / sandbox permission

The model may propose an operation. It must not be the component that decides whether its own proposal is authorized.

Bind approval to state, not only parameters

Parameter matching is necessary but insufficient. A reviewer may approve a patch against Git commit abc123; before execution, another process changes the branch. The command is unchanged, but the state it will affect is not.

The approval fingerprint should therefore bind the action to relevant preconditions, for example:

{
  "action": "publish_release",
  "project_root": "D:/work/app",
  "git_commit": "abc123",
  "artifact_hash": "sha256:...",
  "expires_at": "2026-08-22T14:10:00+08:00",
  "nonce": "approval-7f2..."
}

Immediately before the side effect, the Runtime recalculates the fingerprint. A state mismatch, expiry, or repeated nonce rejects execution. This closes a common time-of-check/time-of-use (TOCTOU) gap.

Network retry is not renewed authority. A retry may safely return the stored result for the same operation identifier; changing the target, parameters, or bound state requires a new approval.

Static parsing still needs a sandbox

Command and path parsing cannot prove every effect in advance. Shell expansion, symlinks, environment variables, child processes, and tool-specific behavior can escape a naive allowlist.

That is why policy gates must sit above hard controls:

run high-impact tools in a restricted process or container;
grant the process only the filesystem and network access it needs;
canonicalize paths and reject traversal outside the bound root;
record command, exit code, stdout/stderr location, and artifact hashes;
fail closed when identity, state, or approval evidence is missing.

What the implementation tests establish

In the public CodeFlowMu Runtime, the tested chain separates Skill context routing, role/tool capability, operation authorization, approval persistence, and one-time consumption. On the pinned implementation used by the research article, 22 focused gate tests plus 13 approval persistence/consumption tests passed: 35/35.

That result supports the tested paths. It is not a penetration test, a third-party security certification, or proof that every downstream tool has perfect target parsing. The remaining boundary matters as much as the green count.

An audit checklist you can use

For every high-impact Agent action, require a concrete answer:

Can the Skill directly invoke effects, or only propose a structured request?
Is role capability enforced in deterministic code?
Is the canonical project root part of the request?
Does policy inspect the real target and side effect?
Is approval bound to parameters and relevant state?
Does approval expire and resist replay?
Does the underlying process lack unnecessary filesystem/network rights?
Can a reviewer reconstruct who proposed, authorized, executed, and verified the action?

The architecture rule is simple: let Skills explain and propose; let deterministic software authorize and execute.

Full evidence matrix, source links, and implementation boundaries are preserved in the canonical English article. A Chinese version is also available.

More bilingual Agent engineering research: JoinWell52 Research Center

DEV Community