Intent is not evidence
A policy document describes what someone intended to configure. It does not show what permissions an identity can actually exercise at runtime. The gap between intent and effective state is where privilege creep lives — and it is precisely what a reviewer cannot find by reading your JSON.
That said, a policy retrieved from a deployed environment is configuration evidence, not merely an expression of intent. The problem is not that the document is meaningless; it is that it is insufficient on its own to establish complete effective permissions.
Cloud authorization does not work by intersecting every applicable policy layer equally. In AWS, same-account identity-based and resource-based grants can combine to allow access — either can independently authorize a request. Permissions boundaries and service control policies constrain what identity-based policies can grant; they do not add permissions. Explicit denies override allows regardless of where they appear. The result is that effective permissions are not a simple intersection of all layers: the combination of grants and constraints depends on which layer types are in play and whether the request is cross-account. Showing a policy document alone proves only that someone wrote it — not what the combination of all applicable layers actually permits at runtime.
NIST SP 800-53 Rev. 5 control AC-6(9) requires logging the execution of privileged functions — an acknowledgment that grant and use are separate things that both require evidence (Source: NIST SP 800-53 Rev. 5). NIST SP 800-207 articulates, as a zero-trust architecture principle, that access should be treated as a per-session decision evaluated against current context — which means the configured entitlement and the runtime authorization decision are distinct, and both require evidence (Source: NIST SP 800-207).
The practitioner consequence: if your evidence of least privilege is a policy document, an architecture diagram, or a compliance dashboard score, you have demonstrated intent. You have not demonstrated state.
Least privilege requires a baseline, not just a shorter policy
Before assessing whether an identity has too much access, establish what access it actually needs. NIST AC-6 defines least privilege in relation to assigned organizational tasks — the principle is not to minimize permissions in the abstract, but to limit them to what the identity requires to perform its function.
The artifacts described in subsequent sections can show that selected actions are allowed or denied. They cannot, by themselves, establish whether the remaining access is necessary. A role may be unable to delete one S3 bucket while retaining unnecessary access to other sensitive resources. That is a constrained role, not a least-privileged one.
The minimum additional evidence needed to close this gap: an approved description of the identity's purpose and the action/resource scope that purpose requires, paired with the observed effective permissions for that identity. The comparison between what is required and what is permitted is what a least-privilege claim actually rests on. When testing that a sensitive permission is absent, also verify that the work the identity is supposed to perform remains possible — a role that cannot do its job is not a least-privilege success.
What makes an artifact inspectable
An artifact is inspectable when an independent reader — one with sufficient context about the identity's purpose and the intended restrictions, but without prior involvement in the configuration — can trace each conclusion to its requirement, its test inputs, its result, and its limitations.
Three properties determine this:
Specificity. The artifact names an actual identity, resource, or action. "The developer role has read-only access" is a claim. An effective-permissions query result showing arn:aws:iam::123456789012:role/dev-pipeline with a resolved permission set is an artifact. Specificity lets a reader verify scope rather than trust a summary.
Falsifiability. The artifact exposes what was tested and what the result was, including what was not tested. A deny result from an actual authorization attempt is falsifiable. A policy attachment list is not, because the reader cannot tell from the list alone whether the deny would hold under a different session context or resource condition.
Independence. The artifact can be reproduced by someone other than the person who produced it, using documented inputs. An IaC diff in version control is reproducible in the sense that the code state is fixed. Note, however, that checking out the same commit does not recreate the authorization state: the live policy versions, resource attributes, and session context at the time of the original query also matter, and those should be preserved alongside the raw output. A screenshot of a console page is not reproducible — the console state may have changed, and the reader cannot rerun the query.
Three artifacts a non-specialist can check
These three together — effective permissions for a named identity, a deny result from an actual attempt, and an IaC diff — give a reader checkable evidence without requiring them to parse your policy language. CLOUD-IAM-002 covers the deeper mechanics of effective permission analysis and entitlement risk scoring; what follows is the minimum inspectable surface.
1. Effective-permissions query output for a named identity
On AWS, aws iam simulate-principal-policy evaluates identity-based policies, one permissions boundary, and service control policies, including their condition keys and resource scoping. Understand its limitations before citing its output:
- Outside the console, you must supply resource-based policies explicitly; the API does not retrieve them for you.
- Resource-based policy simulation is unsupported for IAM roles, which matters if the identity being evaluated is a role ARN.
- Results can diverge from live behavior for role chaining, VPC endpoint policies, and multiple resource-based policies on the same resource. Resource control policies are also not supported.
- Missing condition-key values can produce an implicit deny even when the live policy would allow the request. If context values relevant to the policy conditions are absent from the simulation call, the result may not reflect actual runtime behavior.
When recording simulation output, preserve the complete response — including any MissingContextValues fields — alongside any simplified display. Cite the output for what it evaluated, not as proof of everything that applies.
On GCP, Policy Analyzer for allow policies reports access derived from allow policies for a given principal and asset. It does not account for IAM deny policies or Principal Access Boundary policies, which can independently restrict access; those require separate evaluation. Policy Troubleshooter assesses a specified principal, resource, and permission within its supported scope and subject to the policies the operator can inspect — it is not a full-environment query. Treat results from either tool as partial, and document which policy types were not covered.
Store the raw JSON or CLI output, not a screenshot. Tag it with the identity ARN or principal ID, the timestamp, the commit SHA of the IaC state at time of query, and the relevant policy versions and resource attributes used in the evaluation. That combination gives a reader the inputs needed to assess what the result actually covers.
2. A deny result from an actual authorization attempt
Simulated policies can diverge from runtime behavior when resource-based policies, VPC endpoint policies, or external account trust conditions apply. A CloudTrail AccessDenied event or equivalent authorization log entry — naming the principal, the action, the resource, and the deny reason — is direct evidence that a control fired for that specific request.
Be precise about what an access-denied result proves. It shows that the specific request was denied. It does not automatically establish that the particular restriction being assessed caused the denial: another applicable policy may have blocked the request independently. Include enough information in the artifact to attribute the result to the relevant enforcement mechanism, or explicitly limit the conclusion to "this request was denied" rather than "this specific control prevented access."
The minimum inspectable record: a log entry showing the error code, the principal identifier, the event name, and the resource the attempt targeted. Note that error-field placement in CloudTrail records is service-dependent; the specific fields to capture may vary by service.
One further safeguard: a denied result is only useful if the test was executed safely. Run authorization tests against disposable or non-production resources wherever possible. The expectation of a denial is not a safeguard against a destructive operation succeeding. Tests that assume failure but are not scoped to safe targets represent an operational risk.
3. An IaC diff showing the reduction
A diff in version control — Terraform, CloudFormation, CDK — shows what permissions existed before and what exists now. A diff is inspectable because it is diff-format: additions in green, removals in red, and the commit history records when the change was made.
However, Git author names and commit timestamps are configurable. Commit history alone should not be described as proof of who made or approved a change. Link the diff to authenticated review records — pull request approvals, code-review sign-offs — and to the authenticated deployment record that shows the diff reached the target account.
The diff plus deployment record closes the gap between IaC state and infrastructure state at the time of deployment. It does not prove that drift has not occurred since. The drift warning in the final section applies here too: the diff-based evidence ages with every out-of-band change made after deployment.
Inspectable artifact table
| Artifact | Asserts or demonstrates | What an independent reader can check | What it still leaves open |
|---|---|---|---|
| Written policy document (JSON/YAML) | Asserts only | That the policy text says what you claim | Whether all layers (SCPs, resource policies, boundaries) produce the same effective result at runtime |
| Effective-permissions query output for a named identity | Demonstrates (within evaluated scope) | The resolved allow/deny for that principal, action, and resource at query time, for the policy types the tool covered | Whether resource-based policies, deny policies, or session context not supplied to the query change the result |
| Deny result from an actual authorization attempt | Demonstrates | That a control fired for that specific attempt under live conditions | Which policy caused the denial; whether a different session context, endpoint, or account trust path produces a different result |
| IaC diff showing permission reduction | Demonstrates (with authenticated review and deployment record) | That the change was committed, reviewed, and deployed | Whether drift has occurred since deployment; whether all live permissions are represented in code |
| Role's AssumeRole trust list | Demonstrates (partially) | Which principals are listed as trusted to assume the role | Whether the trust conditions (MFA, ExternalId, source IP) are actually enforced at runtime |
| Dashboard compliance score | Asserts only | That a tool produced a score on a given date | What the score measures, what it excludes, and whether the underlying policy data reflects deployed state |
| Approved task description paired with observed permissions | Demonstrates (with accompanying query output) | Whether the observed access aligns with the stated business requirement | Whether the task description itself is accurate and current |
Showing the negative
Proving a permission is absent is harder than proving one is present, and it is what a least-privilege claim actually requires.
A policy with 12 actions attached is easy to read. A policy that is missing the 13th action — the one that matters — requires you to enumerate what was asked and denied, not just show a shorter list. Absence is not visible in a policy document; it is only visible in a tested result.
The operational approach: for each high-risk permission you claim is absent, produce a simulation or a live authorization attempt that returns a deny. On AWS, simulate-principal-policy with the specific action and resource returns implicitDeny or explicitDeny. Preserve the complete output, including any MissingContextValues, and supply relevant condition-key values so that a simulated deny is not an artifact of missing context rather than an actual policy restriction. A simulated allow establishes the result for the evaluated inputs; confirm it against live behavior before concluding the least-privilege claim is false, since the simulation may not have included all applicable policy types.
# AWS: Check that a named principal cannot call s3:DeleteBucket on a specific resource.
# Supply --context-entries for any condition keys your policies evaluate.
# Preserve full output including MissingContextValues, not just the decision field.
aws iam simulate-principal-policy
--policy-source-arn arn:aws:iam::123456789012:role/dev-pipeline
--action-names s3:DeleteBucket
--resource-arns arn:aws:s3:::prod-data-bucket
--context-entries Key=aws:RequestedRegion,Values=us-east-1,Type=String
# Review EvaluationResults[*].EvalDecision and EvaluationResults[*].MissingContextValues
On GCP, Policy Troubleshooter can assess a specified principal, resource, and permission within its supported scope. Be aware that results reflect the policies the tool can inspect; IAM deny policies and Principal Access Boundary policies require separate evaluation. testIamPermissions checks what the authenticated caller — the credentials making the API call — can do; it is not an arbitrary-principal query and does not produce a record of a denied business operation by another identity. Neither tool is a drop-in substitute for the other, and neither alone constitutes a complete denial record.
For a role with a large action surface, generating deny evidence for every absent permission is operationally impractical. A scoped approach — testing the highest-risk absent permissions based on blast radius or data sensitivity — can produce meaningful evidence without exhausting team capacity. Pair those negative tests with positive checks confirming that the access the identity legitimately requires still works. The decision about what to test should follow your organization's risk tolerance and regulatory obligations, not a universal threshold.
When the evidence requires a tool
Some effective-permissions computations cannot be done manually in reasonable time. Cross-account role chains, attribute-based access control policies with many tag conditions, and SCPs across multiple organizational units can produce a permission space too large to enumerate by hand.
When that is the case, the artifact is the tool's output — not the tool itself. Export the result as structured data. Document what query was run, against what identity and resource scope, which policy types the tool evaluated and which it did not, the date of the query, and the deployed state it ran against. CLOUD-IAM-004 covers tooling evaluation for this class of problem; the manual fallback — simulate-principal-policy scoped to the highest-risk actions, with complete context values supplied — yields a smaller but still inspectable artifact.
If your only evidence of least privilege is a CIEM dashboard score with no exported query results, no deny logs, and no IaC diff, the evidence does not meet the inspectability standard described here, regardless of what the score says.
What this evidence does not prove
Even a complete set of inspectable artifacts has limits. State these explicitly when handing artifacts to a reviewer.
Effective-permissions query results reflect the policy state at query time, for the policy types the tool evaluated. Drift between IaC and deployed infrastructure, out-of-band console changes, and cross-account grants created after the query can all invalidate the result without the query changing. The inputs preserved with the artifact — policy versions, resource attributes, session context — help a reviewer assess how much the state may have diverged, but they do not eliminate the possibility of drift.
A deny result proves that a specific request was denied under those conditions. A different session context — a federated role with elevated session tags, a different source IP condition, or an assumed-role chain — may produce a different result. It also does not identify which policy caused the denial unless sufficient attribution information is included. Revocation and session behavior vary by platform and token type.
The artifacts here are not a substitute for continuous monitoring. They are point-in-time evidence. If your environment has high change velocity, the inspectable snapshot ages faster than the same evidence in a stable environment. Attach a timestamp to every artifact and make the staleness visible.
The independent check test
The practical test for whether your evidence is inspectable: ask a reviewer with no prior involvement in the configuration — someone analogous to an experienced independent reviewer who can assess the work on its merits — to examine the full artifact set. This includes the identity's stated purpose, the expected restrictions, the effective-permissions query output, the deny log entries, the IaC diff with authenticated review and deployment records, and the underlying policies as supporting evidence.
Ask them two questions: Can you trace each stated conclusion to its requirement, the test inputs, the result, and its stated limitations? Can you identify what was tested and what was explicitly not tested?
A follow-up question from the reviewer is not automatically a finding — a competent reviewer may ask clarifying questions that the artifacts should be able to answer. The signal is whether the reviewer must rely on your explanation to reach the conclusion, rather than on the artifacts themselves. If they cannot trace a conclusion without your help, revise the artifacts or their accompanying documentation before presenting them to an external audience.
This test works across audience types — a colleague from a different team, an independent engineer, or a peer reviewer from a compliance function — because it does not require the reviewer to share your policy-language expertise. The artifacts and their documented context do the explaining. If they do not, that gap is what an external reviewer will record as a finding.
Sources
- NIST SP 800-53 Rev. 5: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- NIST SP 800-207: NIST SP 800-207
