All-or-nothing does not survive contact
File-based architecture repositories have exactly two access levels: you can open the folder or you cannot. That works while the only people involved are architects who all see everything.
It stops working the first time a delivery team wants to see their own project's architecture, or a supplier needs one integration model, or a regulated business line's architecture must not be visible to the rest of the organisation. At that point the choice is between giving them everything and giving them nothing, and both answers are wrong.
Two layers, not one
The model that holds up is a global role describing what kind of user someone is, plus scoped grants describing what they may touch.
The global role answers "can this person administer the platform, model, or only read". The grants answer "where". A user might be an Architect globally, with edit rights on the Payments repository and read rights on one project inside another.
Keeping these separate matters because they change for different reasons. A promotion changes the role. A project reassignment changes the grants. Conflating them produces a permission matrix that has to be re-derived every time either changes.
Groups, not people
Grants should attach to groups, and groups should come from the identity provider wherever possible. This is unglamorous and it is what makes access control survive the second year.
Permissions granted to named individuals decay silently. Someone changes team and keeps access. Someone leaves and their grants persist because deprovisioning covered the IdP account and not your application's internal ACLs. A grant to Payments Architecture follows the joiner-mover-leaver process automatically; a grant to Jan does not.
If you find yourself granting to individuals routinely, that is a signal your groups do not match how work is actually organised — which is worth fixing at the group level rather than working around one grant at a time.
The effective-permission problem
With roles, groups, inherited repository grants and project overrides, the question "what can this person actually see" stops being obvious. Administrators guess, and guessing about access control is how leaks happen.
An effective-permission view — pick a user, see the resolved answer per repository and project, with the reason each grant applies — is not a nice-to-have. It is what makes the model administrable, and it is the first thing an access review will ask for.
The "why" column matters as much as the answer. "Read, because of membership of Payments Architecture" tells an administrator what to change. "Read" alone tells them to start hunting.
Deny is a trap
Sooner or later someone asks for an explicit deny — this group has access to the repository, except this one project. It is a reasonable request and it is worth resisting.
Deny rules make effective permissions genuinely hard to reason about, because the answer now depends on rule precedence rather than on the union of grants. Every subsequent question about access requires simulating an algorithm rather than reading a list.
The alternative is almost always available: do not grant at the repository level, grant at the project level to the projects that should be visible. More rows, dramatically simpler reasoning.
Where scope boundaries actually fall
Two layers describe the mechanism; they say nothing about where to draw the lines, and the lines are where the design succeeds or fails. Scope boundaries that mirror this quarter's org chart are the tempting choice and the wrong one, because the org chart will be different before the permission model is a year old, and every reorganisation then becomes a permissions migration.
The boundaries that age well follow the architecture itself: business domains, regulated perimeters, delivery programmes with a real start and end. Payments, Customer Data, the ERP replacement — these survive reshuffles that rename every department around them. A useful test before committing: imagine the two most likely reorganisations, and ask whether the boundary would move. A boundary defined by "what the Payments platform is" stays put when the Payments teams are re-split; a boundary defined by "what reports to Anna" does not.
Granularity has a natural floor. Repository and project scopes earn their administration cost; per-package or per-element permissions almost never do. Below the project level the grants multiply faster than anyone can review, the effective-permission question becomes genuinely hard, and the practical need — "this team works here, that team reads there" — was already met two levels up. When a single package inside a project truly needs different visibility, that is usually the model telling you it belongs in a different project.
The cross-cutting reader
Every estate has a handful of people whose job is to see across it: the security architect threat-modelling a change, the auditor sampling controls, the PMO tracking programme dependencies. The wrong way to serve them is the way it usually happens — grants accumulating one project at a time until their access list is longer than anyone can explain, and an access review finds a business analyst with write rights to nineteen repositories no one remembers granting.
The right way is to admit the need into the role model: a global read role, deliberately named — Estate Reader, Assurance — granted sparingly, reviewed by name, and carrying read only. Read-everything is a legitimate job requirement; write-everything is not a job, it is an incident waiting for an author. Keeping the two apart in the role model means the access review can bless the first in one line and interrogate any instance of the second.
Externals, suppliers and the grant that outlives the contract
The hardest population is the one that does not belong to you. A supplier building one integration needs the models for that integration — not the estate, and not forever. Both halves of that sentence need mechanical enforcement, because both fail socially: scope creeps because granting wider was easier, and duration creeps because nothing ever expired.
Guest identities from the IdP, project-scoped grants, and — the part most platforms skip — an expiry date on the grant itself, with a named internal sponsor who gets asked before it renews. The renewal question is the control: "does the Acme integration team still need read access to Payments Integration?" is answerable by the sponsor in ten seconds, and the default answer after the contract ends is no. Where the platform cannot expire grants natively, a scheduled report of external grants older than ninety days is a serviceable substitute; what does not work is memory. In our experience the longest-lived credentials in any estate belong to suppliers whose projects shipped years ago, for the simple reason that nobody's leaver process covers other companies' leavers.
Search has to respect this
A detail that is easy to miss until it leaks: search results, model inventories, audit views and any "recently changed" list must all be filtered by the same permission model.
It is not sufficient to block access to the model itself. If a search returns the names of elements inside a project someone cannot open, you have disclosed that a project exists, what it is called, and roughly what it contains. For an organisation where a project name is itself sensitive — an acquisition, a restructuring — that is the leak, and no one will notice it happening.
Reviewing access without it being a chore
Every regulated organisation requires periodic access review, and most reviews are performed badly because the artefact presented is a list of user-permission pairs that nobody can evaluate.
What a reviewer can actually assess: a list of people who have write access to each repository, grouped by grant reason, with the date the grant was made and when it was last used. The last-used column does most of the work — a write grant unused for a year is the obvious candidate for removal and requires no judgement about org structure.
If your repository cannot report when a grant was last exercised, access reviews will be theatre. That single field turns an unreviewable list into a short, actionable one.
Permission changes are events worth keeping
Access control has two audit surfaces, and most platforms only build the first: what the permissions are. The second is how they got that way — who granted what, to whom, when, and on whose request. Without it, the effective-permission view answers today's question and nothing about last March, which is precisely the month the review will ask about.
The implementation is not demanding: every grant, revocation and role change written as an immutable event, alongside the model changes and publications the platform already records. What it buys is the ability to answer the awkward questions cheaply — when did the supplier get write access, who approved widening that group's scope, was the leaver's access actually revoked on the date HR says they left. These are the questions that consume days when the answer lives in old emails, and minutes when it lives in the platform's own records.
One alert is worth wiring on top: any change that widens administrative rights. Not because the administrators are suspect, but because a privilege escalation nobody remembers making is the single loudest signal of either a compromised account or a process being bypassed — and it is a signal that costs one notification rule to hear.
Retrofitting scopes onto an open estate
Everything above is straightforward on a green field. The common reality is an estate where everyone has seen everything for years, and the first scoped project — the acquisition, the regulated business line — arrives with a deadline. Narrowing access that people already have is organisationally harder than granting it, and pretending otherwise is how the initiative stalls.
The sequence that works runs in one direction: leave read access broadly open at first, scope write access immediately, and only then narrow read where there is a stated need. Write-scoping is uncontroversial — architects mostly agree they should not be able to edit models they do not own — and it delivers most of the integrity benefit on day one. Read-narrowing is the political half, and it goes better announced as a rule ("regulated perimeters are visible to their teams and to Assurance") than negotiated model by model with everyone who currently has access.
Two things make the transition stick. First, the sensitive project that triggered all this starts scoped from its first day — retrofitting is for the existing estate, not the new perimeter. Second, publish the rule alongside the rest of the practice's operating rules, so the next request for an exception is a question about the rule rather than a favour from an administrator. Permission models fail socially before they fail technically; a written rule is the social half of the design.
The joiner case
Well-designed permission models often make joining harder than they should. A new architect needs access to five projects, and each is a separate grant made by an administrator who has to be asked.
Group-based grants fix this if the groups match how teams are actually organised. When someone joins Payments Architecture, membership of that group should be sufficient. If joiners routinely need individual grants on top, the group structure does not reflect reality and is worth fixing at that level rather than by processing exceptions.
Where permissions meet the published portal
Everything so far concerns the repository, where the permission model can be enforced at the moment of access. The estate usually has a second exit: a published portal, generated from the models and read by an audience far wider than the modelling tool's user list. The two access models have to be designed together, because the portal can undo the repository's discipline in one publication.
There are two honest shapes. The first is a portal built from a deliberately public subset — the scope filter runs at generation time, the sensitive perimeters simply never enter the output, and the result can be hosted as a static site with no runtime authorization at all. Its security argument is pleasingly short: what is not in the files cannot leak from them. The second is an authenticated portal that mirrors repository permissions at read time, which serves the "one portal for everyone, each seeing their slice" ambition but drags every page, search index and cross-reference into the authorization problem. Both are defensible. What is not defensible is the accidental third shape: a portal generated from everything and protected by nothing but an obscure URL, which is how a scoped repository leaks in practice — not through the front door with its two-layer model, but through the publication nobody threat-modelled.
The practical guidance is one sentence: the portal's scope is a permission decision, so it belongs to whoever owns the permission model, expressed in the publication pipeline's configuration — not to whoever happens to maintain the generation scripts. When the acquisition perimeter is scoped in the repository on Monday, the question "and is it excluded from the portal build?" should have an owner, a config file, and an answer that does not depend on anyone remembering.
A closing observation from estates that have run this model for a few years: the permission system's real product is not restriction but confidence. Architects model candidly — including the unflattering current state — precisely because they know who can see it. Business lines bring sensitive work into the shared estate instead of hiding it in slide decks, because the perimeter is enforced rather than promised. The alternative to scoped permissions was never an open estate; it was an estate missing everything anyone cared about protecting, with the real architecture living in email attachments. Measured against that, the administration cost of a role, a handful of groups and an effective-permission view is the cheapest control in the whole practice.
A starting matrix
For a practice setting this up for the first time, the temptation is to design the perfect model before granting anything. Resist that too. The matrix below is where most estates should simply start; every refinement in this article can be added later, when a real case demands it, and half of them never will be.
| Group | Global role | Scoped grants |
|---|---|---|
| Architecture team | Architect | Edit on their domain repositories |
| Each delivery team | Reader | Read on their project |
| Assurance / security | Estate Reader | — |
| Platform administrators | Administrator | — (two people, named, reviewed) |
| Suppliers | Reader | Read on their project, with expiry |
Five rows, four groups from the directory, one deliberate exception. An estate run on exactly this matrix for its first year will pass its access review, survive its first reorganisation, and accumulate the evidence to justify every refinement it eventually needs — which is more than can be said for most estates that started with something cleverer.