Skills governance — prove every AI agent skill stayed in its authority
AI agent skills and Model Context Protocol (MCP) servers are the newest thing your developers install — and the newest attack surface. A supply-chain scanner tells you a skill artefact is clean. It does not tell you what the running skill then did. KYE Protocol™ governs that: which servers a skill called, which scope it touched, which actions it took — refused at the boundary if outside its grant, and sealed into an Evidence Pack™ you can re-verify from a public key. It cuts a skill-incident investigation from days to minutes.
Why this is urgent now
You are installing agent skills and MCP servers faster than anyone is governing them — and the data shows the gap is already being exploited.
- 969 malicious AI agent skills were detected in a single year (JFrog 2026 Software Supply Chain Security State of the Union), alongside 495 malicious AI models — attackers are beating defenders on the newest surfaces.
- 18% of organisations have no governance for IDE extensions or MCP servers at all — an open door for the agent layer.
- 97% claim AI governance; 53% still pull from uncontrolled registries. As that report puts it, visibility without accountability is not governance — confidence is not control.
The lifecycle: scanners own the artefact, KYE™ owns the action
A skill has a whole lifecycle, and supply-chain security only covers the first half. KYE™ owns the runtime half — and that is where authority lives.
Green = supply-chain scanners (the artefact). Accent = KYE Protocol™ at the action boundary (the runtime).
| Lifecycle stage | Who covers it | The question answered |
|---|---|---|
| Author → publish → install | Supply-chain scanners (e.g. artefact registries) | Is the skill artefact free of known malware and from a curated source? |
| Invoke (runtime) | KYE™ | Was this call to this MCP server, this scope, this action class inside the skill's declared authority? |
| Evidence | KYE™ | Is every consequential skill action a signed Evidence Pack™, verifiable from public keys alone? |
| Revoke | KYE™ | When a skill is compromised, can you prove exactly what it was ever authorised to do, and suspend it with finality? |
A clean skill can still exfiltrate if it calls a server it never declared or reads a path outside its scope. KYE™ refuses that at the action boundary — the malicious-skill failure mode never executes, and the refusal is itself evidence.
How KYE™ governs a skill — reusing what already exists
Skills governance is not a new product bolted on; it is the KYE™ authority model applied to the skill, so your team adopts it without learning a new system.
- Declared binding per skill. Each skill carries an allow-list of MCP servers, a data scope, and permitted action classes — KYE Protocol™'s delegated-agent binding, applied to the skill.
- Refused at the boundary. An off-list server, an out-of-scope path, or a privileged write the skill was never granted is refused before it runs — with the exact reason code.
- Proven, not logged. Audit proof is derivable from a published key in minutes — not the week-plus most teams need today, which is documentation, not governance.
- Above any agent runtime. Skills governance is one solution on the KYE Agent Authority Stack™ — it sits over whatever framework runs your skills.
The Skill Authority Manifest — every layer maps to an existing KYE™ primitive
A SKILL.md file tells an agent how to act. The Skill Authority Manifest tells the world whether the agent was allowed to act. It is not a new artefact: it is the KYE™ Capability Manifest pointed at a skill — so each authority layer below is an existing KYE™ primitive you already adopt, never a new system to learn.
| Authority layer | What it pins for the skill | KYE™ primitive |
|---|---|---|
| Skill identity | One canonical capability ID and version for the skill — the thing every grant, refusal, and evidence record resolves to. | Capability Manifest |
| Principal binding | Which first-class principal owns and runs the skill — so the action attributes to an accountable identity. | Agent-as-principal |
| Purpose | The single purpose the skill may act for; an out-of-purpose call is refused. | Purpose Permission™ |
| Tool scope | The allow-list of MCP servers, data scope, and action classes the skill may touch. | Delegated-agent binding |
| Risk class | The EU AI Act risk tier and side-effect level that set how hard the gates bite. | Risk classification |
| Approval mode | Whether a consequential call runs straight through or needs a human approver before it executes. | KYE GovernedUI™ |
| Finality boundary | The most consequential outcome the skill may reach — draft, recommend, commit, or submit externally. | Authority Finality™ |
| Evidence | What seals into the signed pack on every consequential call, so the action is replay-verifiable from public keys alone. | Evidence Pack™ |
| Revocation / expiry | A hard expiry and an out-of-band suspend, so authority always ends and a compromised skill stops with finality. | Time-bound grant |
SKILL.md tells an agent how to act; KYE™ tells the world whether the agent was allowed to act. The manifest is the bridge: nine authority layers, every one an existing KYE™ primitive, sealed into one record an auditor can replay.