IAM dashboards show governed entitlements as they are intended to exist, while developer workflow visibility shows how access is actually created, stored, and used inside repositories. Teams need both views because a clean directory does not prove clean repository access.
What each view is actually showing
Developer workflow visibility and IAM dashboard visibility answer different questions. An IAM dashboard is a control-plane view: it tells you what roles, groups, policies, and entitlements are supposed to exist. Developer workflow visibility is an evidence-plane view: it shows how access is actually created, stored, inherited, and used in code, CI/CD, repositories, secrets managers, and automation.
That distinction matters because the directory can look clean while repository reality remains messy. A team may have removed obvious standing access in the IAM console, yet still leave tokens in pipelines, hardcoded secrets in config, or broad access embedded in workflow files. The workflow view is where those paths become visible.
Why the two views diverge in practice
The IAM dashboard usually reflects governed state after policy and review. It is useful for entitlement review, access recertification, and reporting, especially when you need to know who should have access. By contrast, developer workflow visibility captures how access is operationalised during delivery, which is where many hidden paths appear. For example, a repository may inject short-lived or long-lived secrets into build jobs, call cloud roles from automation, or reuse credentials across environments, all without changing the directory picture.
In practice, the workflow view is closer to where access is introduced and consumed. That makes it better for spotting drift between intended governance and actual technical use. For a broader identity and lifecycle perspective, NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs help frame why created, rotated, and deprovisioned access must be tracked where it is used, not only where it is approved.
What teams miss when they rely on only one view
Relying only on IAM visibility can hide developer-side exposure such as overbroad pipeline permissions, stale secrets in repositories, cross-environment reuse, or access paths created by automation rather than humans. Relying only on workflow visibility can also mislead, because seeing a token in a repo does not tell you whether it is still authorised, overprivileged, or formally owned. The two views are complementary: one shows intended governance, the other shows operational reality.
That is why audit-style dashboards and delivery-time telemetry should be reconciled. If the dashboard says access has been removed, but a workflow still succeeds with an old credential or a service identity still has repository-adjacent permissions, the control is not actually closed. The same logic appears in Top 10 NHI Issues and Cloud Workload Identity Guide, where lifecycle and runtime usage must both be understood to manage access safely.
Risk and Threat Considerations
When organisations treat IAM dashboards as the source of truth, they can miss active exposure in repositories and pipelines. That gap creates hidden persistence, privilege creep, and secret sprawl, especially when workflow access is inherited through automation rather than manually assigned.
Failure mechanism: A governed entitlement is removed or looks benign in the dashboard, but an older secret, token, role assumption path, or embedded automation still grants access in the developer workflow.
Impact: Attackers or careless insiders can continue to use undeclared access paths, making compromise harder to detect and remediation incomplete. CSA Cloud Controls Matrix and OWASP Cheat Sheet Series both reinforce the need to control secrets, authentication, and least privilege where they are operationally used.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Compares governed entitlements with operational access paths that must be managed. |
| Recommendation — Inventory and govern accounts across repositories, pipelines, and automation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Workflow access often depends on secrets and tokens that must be controlled lifecycle-wide. |
| AC-6 — Least Privilege | The question hinges on whether effective access in workflows exceeds intended entitlement scope. | |
| Recommendation — Rotate and retire authenticators used in developer workflows on a defined schedule. Restrict workflow permissions to the minimum required for each repository and pipeline. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | This distinction separates approved access governance from actual access use in delivery workflows. |
| Recommendation — Define access rules that cover both IAM approvals and repository-level execution paths. | ||
| OWASP ASVS | V8 — Authorization | Repository and pipeline access must be validated against the actual authorization path, not just the directory view. |
| Recommendation — Verify that workflow actions are authorized only for the intended repository and service identity. | ||
Practitioner Guidance
What to verify: Confirm that every meaningful repository, pipeline, and automation path has an owner, an expiry or rotation expectation, and a traceable link back to the approved entitlement model. If a workflow can still authenticate after the IAM record looks clean, treat that as a control failure, not a documentation issue.
Decision rule: Use the IAM dashboard for governance decisions, but use developer workflow visibility to decide whether access is truly gone. If the two disagree, trust the workflow evidence first and remediate the underlying secret, token, or role path before closing the ticket.
Practitioner takeaway: Clean IAM state is necessary, but it is not sufficient. The practical test is whether access can still be created, stored, or exercised inside delivery workflows after the dashboard says it should not exist.
Related resources from NHI Mgmt Group
- What is the difference between human IAM controls and NHI governance?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?