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.

Skills governance: side by side

Demo data

You learn: How the options differ, criterion by criterion. You can: Pick a column to light it.

Author → publish → installSupply-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?
EvidenceKYE™Is every consequential skill action a signed Evidence Pack™, verifiable from public keys alone?
RevokeKYE™When a skill is compromised, can you prove exactly what it was ever authorised to do, and suspend it with finality?
How this widget is built
Demonstrates
Comparison
Components
  • The options this page compares
  • The criteria it compares them on
Flow
Each criterion across the options, as the page sets it out. Architecture diagram
Used on

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.

Author

skill written

Publish

to a registry

Install

scanned for malware

Invoke

authority checked

Evidence

Evidence Pack™ sealed

Revoke

suspended with finality

Green = supply-chain scanners (the artefact). Accent = KYE Protocol™ at the action boundary (the runtime).

Lifecycle stageWho covers itThe question answered
Author → publish → installSupply-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?
EvidenceKYE™Is every consequential skill action a signed Evidence Pack™, verifiable from public keys alone?
RevokeKYE™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.

Start a skills-governance pilot

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 layerWhat it pins for the skillKYE™ primitive
Skill identityOne canonical capability ID and version for the skill — the thing every grant, refusal, and evidence record resolves to.Capability Manifest
Principal bindingWhich first-class principal owns and runs the skill — so the action attributes to an accountable identity.Agent-as-principal
PurposeThe single purpose the skill may act for; an out-of-purpose call is refused.Purpose Permission™
Tool scopeThe allow-list of MCP servers, data scope, and action classes the skill may touch.Delegated-agent binding
Risk classThe EU AI Act risk tier and side-effect level that set how hard the gates bite.Risk classification
Approval modeWhether a consequential call runs straight through or needs a human approver before it executes.KYE™ GovernedUI™
Finality boundaryThe most consequential outcome the skill may reach — draft, recommend, commit, or submit externally.Authority Finality™
EvidenceWhat seals into the signed pack on every consequential call, so the action is replay-verifiable from public keys alone.Evidence Pack™
Revocation / expiryA 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.

Canonical KYE™ surfaces referenced on this page: Authority Graph™ · KYE™ MCP Server · Purpose Permission.