The Blueprint Inspector: How PanIAM Secures Your Cloud Without Touching Your Data

You’ve been here before.

A vendor asks for access to your AWS account. They promise they’ll be careful. They send over a permissions policy that looks like it was written by someone who Googled “AWS IAM” five minutes ago. Admin access, write permissions, maybe even a long-lived API key they’ll store “securely” on their side.

Three months later, you discover they had write access to your production database. Or their key leaked. Or they scanned data they had no business seeing.

If this sounds familiar, you’re not alone. Over-permissioned SaaS integrations are one of the most common, and most preventable, risks in cloud security today.

We built PanIAM knowing this. We don’t need to see your data. We just need to read the blueprints.

The problem: why SaaS access is broken

Most security tools ask for more access than they need. It’s not always malicious, it’s often just lazy. Broad permissions are easier to set up than precise ones. Long-lived API keys are simpler to manage than temporary credentials. And most vendors don’t bother distinguishing between “reading the wiring diagram” and “opening every drawer.”

The result? You end up with a tool that can:

• Read your S3 bucket contents when it only needed to list bucket policies
• Access database records when it only needed to check encryption settings
• Write to your infrastructure when it only needed to observe it

It’s like giving a building inspector a master key to every room, safe, and filing cabinet, when all they needed was the floor plan.

Blueprints, not belongings

PanIAM works differently. We read your configuration, not your data.

What does that mean in practice? PanIAM looks at:

• IAM policies: who has access to what, and how those permissions are structured
• Resource configurations: how your services are set up, what’s exposed, what’s encrypted
• Network topology: how your VPCs, subnets, and security groups are wired
• Permission boundaries: where the guardrails are, and where they’re missing

What PanIAM does not look at:

• The contents of your S3 buckets
• Your database records
• Your application secrets
• Your live servers and running applications

Picture a building inspector who reviews your floor plans, fire exits, and wiring diagrams to find structural risks. They check whether the emergency exits are accessible and the electrical wiring meets code. They never open your filing cabinets or read your documents.

When configuration alone isn’t sufficient (for example, during vulnerability scanning of container images), access is strictly read-only. No write permissions, ever.

And here’s the part that matters most: you create the role in your own AWS account. You define what the inspector can see. You hold the keycard.

How you grant access to PanIAM

The setup works like hiring an inspector. You don’t give PanIAM a copy of your keys. Instead, you create a dedicated access point in your AWS account, specifically for PanIAM, with the permissions you choose. PanIAM can look through that access point, but only at what you’ve allowed.

You own this access point. You decide what it covers. And if you ever want to stop the inspection, you simply remove it.

But this setup alone has a gap.

The secret handshake: why External ID matters

The access point you created has an address, and that address is not a secret. It follows a predictable pattern that anyone familiar with your AWS account could guess.

Now imagine this: an attacker also signs up for PanIAM. They guess your access point address and enter it as their own. Without any additional check, PanIAM would have no way to tell the difference between the attacker’s request and yours. Both point at the same address. Both look legitimate. The attacker sees your infrastructure, your configuration, your vulnerabilities.

Without External ID:

  Your tenant ──────────── ✅ Granted ──┐
                                        ├──▶ Your access point
  Attacker's tenant ────── ✅ Granted ──┘

This is called the confused deputy problem. The “deputy” (PanIAM) gets tricked into acting on behalf of someone who shouldn’t have access.

External ID solves this. During onboarding, PanIAM generates a unique secret code for your account. You add this code as a requirement: “Only grant access if the caller provides this exact code.” Your PanIAM account knows the code. The attacker’s does not. Even if they guess the right address, their request is rejected.

With External ID:

  Your tenant (code "X") ──────── ✅ Granted ──┐
                                               ├──▶ Your access point (expects "X")
  Attacker's tenant (code "Y") ── ❌ Denied ───┘

External ID is an AWS best practice that many tools skip. PanIAM enforces it.

No lingering access: temporary by design

PanIAM doesn’t store credentials. Every time we need to access your configuration, we request a temporary session from AWS, one that expires after 15 minutes. There are no long-lived keys sitting in a database somewhere. No API tokens that could leak in a breach.

It works like a visitor badge that expires every 15 minutes and must be re-issued each time. If PanIAM’s systems were ever compromised, there would be no stored credentials to steal.

And if something goes wrong with the integration, if a permission changes or the role is misconfigured, our health check system notifies you. No silent failures, no guessing. You know exactly when something needs attention.

You stay in control

This is the part most vendors don’t talk about: what happens when you want to stop.

With PanIAM, you delete the IAM role in your AWS account. That’s it. Access stops immediately. No support ticket. No waiting period. No “we’ll process your request in 5-7 business days.”

You created the role. You control it. You can revoke it in seconds.

And while the access is active, PanIAM lets you see exactly what each provider can reach in your account. No guessing, no trust required.

It’s like escorting the inspector out of the building, or just changing the locks. Either way, it’s instant, and it’s entirely your decision.

Why this matters

We built PanIAM because we’ve lived on the other side of this problem. We’ve seen what happens when a vendor has too much access, when credentials leak, when “read-only” turns out to mean “read everything.”

Our access model isn’t an afterthought. It’s foundational:

• Configuration first: we read blueprints, not belongings
• Your role, your rules: you create and control the access
• External ID enforced: no confused deputy attacks
• Temporary credentials: nothing stored, nothing to leak
• Instant revocation: delete the role and we’re gone

We don’t want your keys. We just want to check the locks.

If you’d like to see how the onboarding process works, or review the exact permissions we request, drop us an email. We’re happy to walk you through it.