# 05 — Skills, identity and permissions

The most consequential design in the cluster, and the least built. Two briefs carry it: the 4 June NHI intersection and the 18 June OAuth critique.

---

## 1. A skill comes with its identity and permission set

> a skill *"must come with the identity and permission set needed to execute it."*

The insight is the intersection: the skills series says skills capture how a business operates; the NHI series says nothing should run without a scoped identity. Put together: **a skill without an identity is a capability that will be executed with someone else's over-broad credentials** — which is how every automation gets provisioned today.

The use case that grounds it is **joiner-mover-leaver**: onboarding someone into a role means granting the permission sets of the role's skills; moving them means swapping skill sets; leaving means revocation falls out for free. And the synthesis: *"**a role's needed resources are the skill.**"*

Plus the business case, which is the unglamorous half: **under-provisioning waste** — people blocked waiting for access nobody can enumerate, because the role's needs were never written down anywhere. A skill with a declared permission set *is* that enumeration.

---

## 2. Units of execution — the generalisation

From 18 June, and it widens the principle beyond skills:

> *"the same applies to **every unit of execution: the package, the code, the skill, the agent, and the tool**, each of which should declare or have dynamically calculated the permissions it needs."*

That is the SBOM instinct applied to authority — and the corpus already named the artefact: the **PBOM**, the Permissions Bill of Materials (*"you could argue this mapping is more important than the SBOM"*). This site owns the skills column of that table; `open-source.sgit.ai` and `standards.sgit.ai` share the rest.

---

## 3. The OAuth critique

Delivered through skills because skills are what made it urgent:

> *"skills are becoming crazy powerful because they are code, **English is code now**, so they must come with a definition of the permissions they need **or they run riot**."*

And the failure named precisely:

> OAuth *"grants in absolutes, the union of all privileges, all or nothing, is binary at the moment of consent, and **forces you to grant a hundred percent when you need ten percent**, with no way to scope to just the ten percent in the exact moment it is needed."*

The alternative sketched: **the graph-based, moment-of-authorisation model** — authority computed at execution time from the graph of what this skill, in this context, actually touches.

**The honest label:** this is a critique with a direction, not a design with an implementation. Zero shipped skills declare permissions; the moment-of-authorisation model has no code. Publish it as the estate's position on a live industry problem — which it genuinely is — and not as a capability.

---

## 4. What the smallest real step looks like

The site can propose it, because it is one field:

```yaml
# SKILL.md frontmatter
permissions:
  network: [dev.tools.sgraph.ai]     # hosts this skill calls
  vault:   read                       # read | write | none
  spend:   none                       # llm | none
```

Declared, not enforced — enforcement needs the host work. But a declared set is greppable, reviewable and diffable **today**, it makes the PBOM computable for skills, and it is the same declare-before-enforce sequencing the vault app `permissions` block followed. `08__` G2.

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).