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.
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 grounding use case 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. The synthesis: “a role’s needed resources are the skill.”
The unglamorous business case is 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.
Units of execution — the generalisation
“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.
The OAuth critique
“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 smallest real step
One field, declared rather than enforced:
# SKILL.md frontmatter permissions: network: [dev.tools.sgraph.ai] # hosts this skill calls vault: read # read | write | none spend: none # llm | none
Enforcement needs the host work this frontmatter alone cannot do. But a declared set is greppable, reviewable and diffable today: it makes the PBOM computable for skills, and it follows the same declare-before-enforce sequencing the vault app permissions block already followed elsewhere in the estate. See Q5 for the open question this leaves: does the permission set belong to the skill, or the invocation?