Add a skill that designs an org's ABAC model for them.
Most orgs adopting Massdriver have no access model yet. They have some projects, some bundles, and
a rough idea of who does what. Turning that into custom attributes, groups, and policies is the
part they have to get right early, because attribute keys are unique org-wide and changing the
shape later means rewriting every policy that depends on it.
What it does
Look at what already exists — projects, environments, bundles in the catalog, any attributes and
groups already declared — then ask the questions needed to fill in the rest:
- Who are the groups of people? What can each of them do on their own, and where do they need
someone else to approve?
- Which projects belong to whom, and who should be able to see a project versus change it?
- Which environments are safe to deploy into freely, and which need a proposal?
- Which bundles should be available to which kinds of project?
- Is anything reachable from the internet, and who is allowed to make that call?
Then produce the design: the attribute keys with their scopes and allowed values, the groups, and
the policies with their conditions written out. Explain each choice, including which attribute is
carrying which decision, so they can push back on the shape before any of it is created.
Offer to create it — attributes first, then tag the existing projects and environments, then the
groups and policies.
Why the recommendation matters more than the mechanics
The traps are in the design, not the typing. Choosing an attribute that describes the wrong thing,
putting one at a scope where the action they care about cannot read it, or assuming a group is a
boundary — all of those produce a model that looks right and grants far more than intended. A
skill that proposes a known-good shape avoids most of that before it is written.
Later
Once an org has a model, an audit mode that reads it back and reports where it grants more than
intended would be the natural follow-up. The recommendation half is the part worth building first.
Add a skill that designs an org's ABAC model for them.
Most orgs adopting Massdriver have no access model yet. They have some projects, some bundles, and
a rough idea of who does what. Turning that into custom attributes, groups, and policies is the
part they have to get right early, because attribute keys are unique org-wide and changing the
shape later means rewriting every policy that depends on it.
What it does
Look at what already exists — projects, environments, bundles in the catalog, any attributes and
groups already declared — then ask the questions needed to fill in the rest:
someone else to approve?
Then produce the design: the attribute keys with their scopes and allowed values, the groups, and
the policies with their conditions written out. Explain each choice, including which attribute is
carrying which decision, so they can push back on the shape before any of it is created.
Offer to create it — attributes first, then tag the existing projects and environments, then the
groups and policies.
Why the recommendation matters more than the mechanics
The traps are in the design, not the typing. Choosing an attribute that describes the wrong thing,
putting one at a scope where the action they care about cannot read it, or assuming a group is a
boundary — all of those produce a model that looks right and grants far more than intended. A
skill that proposes a known-good shape avoids most of that before it is written.
Later
Once an org has a model, an audit mode that reads it back and reports where it grants more than
intended would be the natural follow-up. The recommendation half is the part worth building first.