Skip to content

Inherited Permission Review

Access review — instantiates Substrate Lineage Risk Audit

Examines the privileges, roles, and access an inherited substrate silently grants the new system — surfacing over-broad rights that came bundled with the platform rather than being deliberately granted.

When a new system sits on an inherited substrate, it doesn't just inherit code and configuration — it inherits privilege. Inherited Permission Review examines the access a substrate silently confers: the roles, service accounts, capabilities, and default grants a template, image, or platform hands the new system for free. Its defining focus is transitive privilege — the access you get simply by sitting where you sit — and it does something the detectors upstream of it don't: for each inherited grant, it forces an explicit keep-or-cut decision rather than letting the access persist by default. It reasons about who can do what because of the substrate, maps where that over-entitlement concentrates, and adjudicates it.

Example

A new microservice is deployed from a shared platform template and inherits the template's default cloud IAM role. Nobody on the team chose that role's scope. The review traces the inheritance channel — the template grants the role, the role attaches to the workload, the workload runs the service — and finds the inherited role carries read access to every storage bucket in the account plus a wildcard privilege to assume other roles, because the template was written years ago for a much broader service. All that excess concentrates in one identity that can reach almost everything. For each grant, the review renders a decision: revoke, scope down to least privilege, or knowingly accept as residual risk with a named owner and an expiry date.

How it works

  • Trace the inheritance channel. Establish what grants the privilege and what that in turn grants, down the chain from substrate to running workload.
  • Resolve effective access. Enumerate the privileges the system actually has, following role chains and nested grants — not just what's declared.
  • Map the concentration. Identify where over-broad inherited rights pile up in a few identities that can reach sensitive resources.
  • Adjudicate each grant. Decide per grant: drop it, scope it to least privilege, or accept it as residual risk with an owner and expiry.

Tuning parameters

  • Effective-permission depth — declared policy versus fully-resolved effective access (role chains, nested groups, assumed roles); deeper is truer but harder to compute.
  • Least-privilege aggressiveness — how far to cut toward the minimum necessary; tighter shrinks blast radius but risks breakage and toil.
  • Grant granularity — review at the role level or the individual-permission level; finer is safer but slower.
  • Acceptance rigor — what an "accept as residual" requires — owner, expiry, justification; stricter prevents silent permanence.
  • Blast-weighting — prioritize grants by what they can reach (production data, other accounts) rather than reviewing every grant flat.

When it helps, and when it misleads

Its strength is catching privilege nobody granted on purpose — the quiet over-entitlement that inheritance makes invisible — and converting each finding into a decision instead of a shrug.

Its difficulty is that effective permissions are genuinely hard to compute: indirect grants, condition keys, and assumed roles mean a review can miss real access or over-cut and break things. And accepted-residual grants rot into permanent exceptions when the acceptance carries no expiry.[1] The classic misuse is rubber-stamping inherited roles as "probably needed" to avoid breakage — the review run backwards to justify the status quo. The discipline is to resolve effective rather than declared access, and to give every accepted grant an owner and an expiry so residual risk can't quietly become permanent.

How it implements the components

Inherited Permission Review fills the privilege-inheritance slice of the archetype — modeling how access travels in, mapping where it concentrates, and deciding what to do about it:

  • inheritance_channel_model — models the grant chain by which the substrate hands privilege to the system.
  • risk_concentration_map — maps where over-broad inherited rights pile up in a few far-reaching identities.
  • residual_inherited_risk_decision — records the per-grant revoke / scope-down / accept-with-owner call.

It decides what should be allowed but does not enforce isolation of an over-privileged component — that containment is Sandbox or Adapter Wrapper's job — and it does not review the non-access inherited settings, which are Configuration Baseline Diff's.

References

[1] The principle of least privilege — that every component should run with the minimum access its function requires — was articulated by Saltzer and Schroeder in their 1975 survey of protection in computer systems. Inherited privilege is exactly where it erodes, because access arrives bundled with the substrate rather than being granted deliberately. ↩