Permission Visibility: what the dashboard tells you

Outcome

By the end of this lesson, you will be able to read the Permission Visibility drawer and act on any Denied entry to restore full discovery.

1. Concept

Most cost tools go quiet when a permission is missing.

The cloud refuses one of their read requests with an AccessDenied, a 403 or an AuthorizationFailed. The tool writes an error into a log nobody reads. Your dashboard shows a number lower than reality, and it looks like good news. Months later an audit finds that a fifth of the estate was never scanned at all.

ZopNight will not do that. Every refusal during a scan is recorded: which cloud, which permission and which region. All of it appears in the Permission Visibility drawer, which opens from any cloud account through “View Permissions”.

What the drawer shows

ACCOUNT: prod-aws-us-east-1

● 1 need more access   ● 14 working

FEATURE                         PERMISSIONS
─────────────────────────────────────────────────────────────────
Needs attention · 1 feature
  Database discovery            Partial            ▸
    docdb:DescribeDBClusters      Not attached
    rds:DescribeDBInstances       Granted
Working
  Compute discovery             Granted            ▸
  Kubernetes discovery          Granted            ▸
...

The drawer is organised by feature, meaning what ZopNight can do with the account, and each feature lists the cloud permissions it needs. A summary line at the top counts how many features are working, how many need more access, and how many are restricted.

Each permission shows one of these states:

• Granted. The last check confirmed ZopNight has this permission.
• Not attached. The cloud refused the check: the permission is missing from the role or policy ZopNight uses. This is a denied entry.
• Partial. The permission works in some regions and not in others.
• Restricted. An AWS Organizations Service Control Policy (SCP) blocked ZopNight from checking. The permission may still work where your SCP allows it.
• Not checked. ZopNight has not checked this permission yet.

For anything that needs more access, the drawer lists the missing permissions and gives step-by-step instructions to fix them, and it shows when the account was last checked.

How often each one is checked

Scans run every 6 hours, and every scan checks every permission again, granted or not. After you grant a missing permission, the next scan picks it up on its own.

If you do not want to wait up to 6 hours, start a scan yourself through the API (POST /resources/refresh). There is no refresh button in the app.

How to fix a Denied entry

A typical fix loop:

1. Open Cloud Accounts → find the account → View Permissions
2. Look at the features that need more access, and expand one
3. Read which permissions are missing, e.g. docdb:DescribeDBClusters
4. Choose how to fix it: update your existing policy, or create a new one
5. Follow the steps and copy the policy the drawer gives you
6. Wait ~30 seconds for the change to take effect across AWS
7. Start a scan through the API (POST /resources/refresh), or wait
   for the next 6-hourly scan
8. Wait a minute or two for the scan to re-check the account
9. Reopen View Permissions
10. The missing permission should now show Granted

Five minutes from spotting the gap to closing it.

Why this matters beyond convenience

Three operational uses:

1. Proving your monitoring is complete. A SOC 2 or ISO 27001 audit asks which cloud resources your monitoring actually covers. This drawer answers it precisely: every category granted, nothing denied. The auditor can open it and see the same thing you did.

2. Buying another company. When you acquire a business, what you most need to know is which parts of their cloud nobody was watching. The drawer tells you in minutes, where working it out by hand takes weeks.

3. Explaining a gap against the invoice. When the ZopNight monthly report and the cloud bill differ by 8 percent, this drawer is the first place to look. If 8 percent of the estate was never scanned, you have your answer.

2. Demo

A common scenario, walked through:

Day 1, Morning:
  Customer connects AWS account with the baseline IAM policy.
  Discovery runs. Permission Visibility drawer shows mostly Granted,
  except DocumentDB (Denied: the customer didn't include docdb:* in policy).

Day 1, Afternoon:
  Customer notices DocumentDB Denied. Sees the missing permission in the drawer.
  Copies the policy ZopNight offers (adds docdb:Describe*).
  Applies it to the ZopNight role.

Day 1, Afternoon + 5 min:
  Customer starts a scan through the API (POST /resources/refresh).
  Discovery re-attempts DocumentDB. Returns Granted.
  Permission Visibility shows All Granted.

Day 1, Afternoon + 6 hr:
  First scheduled discovery sync after the manual refresh.
  Discovery picks up 4 DocumentDB clusters that were invisible before.
  Recommendation engine fires for one of them (RC-193: idle DocumentDB).
  $1,840/month potential savings now exposed.

PRE-FIX:   Estate coverage: 87%, missing $1,840/mo savings
POST-FIX:  Estate coverage: 100%, $1,840/mo recommendation surfaced

The 5-minute permission fix unblocked $22,080/year of savings that was structurally hidden.

3. Hands-on (5 min)

For one of your connected accounts:

1. Open Cloud Accounts → click the account → View Permissions.
2. Scroll the drawer top to bottom. Note any Denied entries.
3. For each Denied entry:
   - Read which permissions are missing
   - Note which resource type and region
   - Estimate how much hidden spend might live there (best guess)
4. If any Denied is in a high-spend category (compute, database, storage):
   - Apply the suggested IAM extension
   - Start a scan through the API, or wait for the next one
   - Verify Granted within 5 minutes
5. If all Denied entries are in low-spend / unused categories: document
   them and accept the gap.

The goal is to know the coverage state, not to close every gap. A team that knowingly excludes a service is far better off than one that doesn’t know it has a gap.

Why this part is console only. Connecting a cloud account is done in the console. There is no way to do it from an assistant, by design: connecting hands over credentials, and that stays a deliberate human step.

Once it is connected, an assistant can read it for you: which accounts are wired up, and exactly what each one is permitted to see. Ask “which accounts are connected and what can we read on each” and you get the table you are looking at now, without opening the console.

Tools that read it afterwards: list_cloud_accounts (read, Explore), get_cloud_account (read, Explore), get_cloud_account_permissions (read, Govern). Connection details are in the MCP integration docs.

4. Knowledge check

Q1

A team’s ZopNight monthly cost report is 8% lower than their AWS invoice. The first thing to check is:

A. ZopNight is broken
B. Currency conversion
C. The Permission Visibility drawer
D. The AWS invoice itself is wrong

Q2

A new region is enabled in the customer’s AWS account. The Permission Visibility drawer shows several permissions as Not checked in the new region. The cause:

A. ZopNight is failing
B. The 6-hour discovery cron hasn’t run since the region was enabled
C. The region is unsupported
D. The credential has become invalid since the region opened

Q3

A SOC 2 auditor asks for evidence of “complete cloud inventory coverage.” Most defensible response:

A. Run a Python script
B. Refer the auditor to AWS
C. Manually count the resources and hand-build a spreadsheet for the auditor to review
D. Screenshot the Permission Visibility drawer showing All Granted across all categories

5. Apply

The Permission Visibility surface is:

• Cloud Accounts → click any account → View Permissions: the main entry point
• Notifications: subscribe to the permission.denied event to be told when a new denial appears

For new connections, the recommended first check is the drawer immediately after connection. Catching gaps on day one is much cheaper than discovering them in an audit on day 180.

Module quiz

You have now completed all four lessons of M1.1. Take the module quiz: 10 questions, 80% to pass.

Related lessons

• M1.2: Discover your estate (next module)
• T4.M4.3: Audit logging

Glossary terms touched

Permission visibility · Manual refresh · Coverage