Case: review a cloud permission proposal

You advise Harbor Club, a fictional community organization. Its data owner, Nina, has approved the intended workflows below. Platform engineer Omar asks for a written permission proposal before making changes. Your task is to reason from the supplied inventory, not to inspect accounts or construct a provider policy.

An effective permission is an operation an identity is allowed to perform on a resource after applicable grants, restrictions, and request conditions are evaluated. A role’s name alone does not establish that result.

Stage 1: read the evidence packet

The storage inventory has four areas. Published notices contain approved public information. Attendance totals contain aggregate counts for internal planning. Member contacts contain private contact records. Summaries contain internal weekly reports. These are distinct resources in this fictional model; their names alone do not enforce permissions.

Public viewing of published notices is independent of these authenticated role grants. Removing a role does not make public information private.

The supplied seven-day activity sample shows daily-report reading totals and writing summaries. It shows no deletes. It does not cover monthly operations, inherited grants, resource policies, or every integration. Nina confirms the export engagement ended, but Omar has not completed its dependency review. Treat these as explicit limits on the evidence.

PredictThe seven-day sample contains no deletes. Is that enough to remove every unused permission from every identity immediately?

No. Usage is a sample, not a complete business specification. Here, the approved workflow independently excludes deletion for daily-report, supporting a narrower proposal. Other identities and rare dependencies still need their own owner-confirmed needs and change review.

Stage 2: write the smallest justified proposal

For each row, distinguish the desired permission from the operation used to implement it. This exercise uses plain-language access rules; actual products combine assignments and conditions differently. Ask Omar to identify other grants that could preserve broad authority even after the visible role is narrowed.

Reveal a model access proposal

For daily-report, propose reading only attendance totals and writing only summaries. Exclude member contacts, published notices, and deletion. For event-editors, propose read/write access only to published notices. For coordinators, propose reading contacts and summaries without adding write rights. Nina owns these business decisions; Omar translates them into the selected service’s supported controls.

For temporary-export, record retirement as the intended outcome. Omar first identifies dependencies and any still-valid authority; Nina confirms an approved replacement if a necessary workflow remains. “No activity observed” alone is not the retirement evidence. No ongoing purpose is approved, so keeping access indefinitely also needs an explicit decision rather than silent drift.

The least-privilege proposal is not simply the smallest possible permission list. It is the narrowest set justified by required work and supported by the platform. If writing a summary also requires a specific supporting operation, Omar should document that dependency for Nina’s review instead of silently restoring administration over everything.

Stage 3: define acceptance before change

Use synthetic resources in the approved validation environment. For daily-report, the acceptance pair is: the intended job reads the designated totals and produces its summary; it cannot read synthetic member contacts or delete source totals. For event-editors, publishing an approved notice works while changing a summary is denied. For coordinators, approved reading works while modification is denied.

PredictOmar narrows the direct role, but an inherited assignment still grants broad access. Does the proposal pass?

No. The intended outcome concerns effective permission, not one edited assignment. Identify and review the other authority path. Keep required work available while correcting the combined grants through the approved change process.

Stage 4: hand over a decision, not a slogan

Your brief should name Nina as purpose owner and Omar as implementation owner, list unresolved dependencies, and identify evidence for allowed and denied outcomes. Schedule the change around the reporting job, define who can authorize a fallback, and set a review trigger after new workflows or staff changes.

A limited exception can be reasonable if it has a specific purpose, scope, owner, expiry, and verification. A broad role restored without that record merely recreates the original uncertainty. Finish with what is proposed, what is verified, and what still requires approval or evidence.