Coder Legion - Recent posts tagged iam

Act Security's Amphi Shrinks a 30,000-Character AWS Policy Down to 7,000

Thu, 03 Sep 2026 18:00:00 +0000

David Kerber pulled up a policy with 30,000 characters in it — right at the edge of what AWS will let you attach to a role — and ran it through a tool called IAM Shrink. A few seconds later it was 25,000 characters. He ran it again: 23,000. One more pass, and it dropped to 7,000. Same permissions, a quarter of the size, no additional attack surface.

That's the kind of problem engineers hit constantly and rarely talk about: AWS IAM policies quickly become unreadable and oversized, and fixing them by hand means collapsing action lists into wildcards without accidentally granting permissions you didn't intend. Kerber built a tool for it because he got tired of doing it manually during consulting work. He's now a Cloud Software Architect at Act Security, which acquired his open-source project, Cloud Copilot, last month and folded it into a new free toolkit called Amphi.

Every tool in Amphi follows the same philosophy: do one thing, do it well, run it in the browser or from the command line, and never send the policy data anywhere. IAM Expand takes a wildcard string like s3:*et*ob* and shows exactly which actions it matches as you type it. It can also invert a policy — take an allow, not action statement and spit back the actual list of what's allowed, pulled from AWS documentation that refreshes daily. IAM Convert turns a policy into Terraform, which Kerber built for the same reason as IAM Shrink: he was hand-converting policies too often. Chain the two together in a CI pipeline — shrink, then convert — and your Git history still shows what you actually intended to grant, even after the policy's been compressed for size.

The policy tester is the one built for how developers already think. Paste in a policy, write expectations against it — "this call should be denied," "this call should be allowed" — and the simulator tells you which statement matched and why. Edit the policy live and the results update as you type. Kerber described it as writing red-green tests for a permission set rather than guessing how it behaves.

The most complex tool handles service control policies and resource control policies — organization-wide rules that can govern every request across hundreds of AWS accounts at once. Kerber's blunt about how well understood these are in practice: "Nobody really understands them. They just think they do — including me." His answer is to run every condition in the policy against every other condition and generate a full truth table. One example he pulled up produced 108 unique permutations, each one showing exactly which combination of conditions leads to an allow or a deny.

Then there's the pair built for scale: IAM Collect pulls every policy type from every account you point it at — Kerber said some users run the free version across 7,000 to 8,000 AWS accounts at a time — and IAM Lens queries that data to determine who can actually do what. Ask it who can access a specific S3 bucket, and it runs roughly 20,000 simulations to return every principal with access, along with which objects they can access. Ask the reverse — what can this one role do — and it merges every attached policy, guardrail, and resource policy into a single answer. Kerber's framing for why that matters: "If an auditor asks you to prove who has access to a bucket with driver's license photos in it, this does that. And it scales. And it's free."

I asked what reachability mapping is actually telling an engineer. His answer was more direct than most vendor pitches: it's showing risk. "The first question is who can do it. The second question is, should they? The delta between those two is risk — and it's not a matter of if that gets exploited. It's a matter of when."

Not everything got a confident answer, and that's worth noting on its own. Asked where Amphi overlaps with Permit.io or Sysdig, Kerber said flatly he doesn't know either tool well enough to compare. He couldn't name a customer. And while Act's commercial platform already covers Azure and GCP alongside AWS, he wouldn't commit to whether the open-source tools ever will — "I don't know one way or another whether we'll pursue that."

The commercial boundary is at least clear. The open-source project stays AGPL: free to run inside your own company, off-limits if you're building a product to resell. Act's paid platform is the bigger, multi-cloud version — AWS, Azure, GCP, identity, network — and Kerber says acquiring Cloud Copilot rather than building it in-house came down to time. The tool was already validated at enterprise scale, the edge cases were already worked out, and in security, speed matters more than pride of authorship. He also says open-source contributions have picked up since the acquisition, not slowed down — Cloud Copilot went from a one-person side project to something with real backing.

His closing point is the one to sit with: the industry's been on a least-privilege journey for years, but the urgency just went up. "An attacker's going to get in, and they're going to exploit every access path you haven't closed." Free tooling that shows you exactly where those paths are is a reasonable bet regardless of which platform eventually wins.

Why Organizations Are Still Missing Out on Passwordless Adoption

Mon, 08 Jun 2026 08:09:44 +0000

According to a 2024 study by Ponemon-Sullivan Privacy Report, it was found that around 76% of organizations surveyed in the US haven't adopted passwordless yet.

Given the rapidly evolving landscape of the internet and AI, the lag in adopting passwordless is a concern worthy of highlighting.

Passwords Are Not Enough Anymore

Hackers have figured out long ago, many ways to obtain passwords. All it takes for an account to be compromised, is one vulnerable service running on a server or side channel attacks and the password would already be sold on the dark web for the highest bidder.

Despite the fact that many organizations have raised the baseline password's complexity to comply with the standards and regulations, there are still other challenges:

Password rotation fatigue employees who may not be very tech-savvy (or use password managers), so they resort to workarounds that could compromise their passwords.
How passwords are stored cannot be ignored.
Security level among applications that do use passwords can be inconsistent. This means for example, your banking application might be very secure but this may not be true if you're using the same password for a partner site or service.
Even passwords that are encrypted at rest can be compromised if the encryption algorithm is weak or contain vulnerabilities.
Hackers often use social engineering to try to guess passwords using password cracking tools. Short and predictable passwords can be cracked anywhere in seconds to a few minutes.

What makes relying on passwords only even more risky, is that around 80% of organizations haven't adopted yet zero trust architecture which means that all it takes is one compromised password or account and hackers can install malware to extract others' passwords (APT). This is as per the same study by Ponemon-Sullivan Privacy Report in 2024.

The above scenarios of course assume that users do not have adequate 2FA configured or their 2FA channels are also compromised (e.g. zero-click attacks on mobile devices).

How Does Passwordless Solve The Problem?

Passwordless implementations such as FIDO2 for example significantly reduce the risks associated with passwords handling because the passwordless device itself becomes the authenticator. This can come in the form of BYOD or for example hardware security keys (e.g. Yubikeys are a popular solution).

When you enroll a passwordless compatible device, the device generates private and public keys. The private key which contains the secret (random number) never leaves the device or cannot be extracted. In addition the private key is calculated from the web service domain alongside the secure secret generated.

>[!TIP]
>Since the private key uses the web service domain alongside the secret, this makes phishing attacks much harder.

Since each login uses a different random challenge signed with the private key, replay attacks become useless.

Some passwordless authenticators may also be compatible with biometric authentication such as face recognition or finger prints which reduces theft risks.

Examples of passwordless solutions:

FIDO2 (Fast Identity Online) -> Most secure
OTP (One Time Password)
Biometric Authentication.
Magic Links (one-time links)
Mobile App-Based
Third-Party Identity Providers (e.g. Azure AD, Okta and Ping Identity)
Certificates and Tokens
Physical Tokens

Why Organizations Are Lagging Behind?

The main challenge organizations still face in passwordless's adoption is account recovery. If passwords are phased out without having reasonably secure options for account recovery, there is a significant risk of access loss.

Other factors contributing to the slow adoption such as legacy systems and employees getting overwhelmed with the change.

No Standard Account Recovery Solution

As of today, organizations are implementing different procedures for account recovery. For example, some organizations would require the employee to come personally to the workplace in order to restore access. Others provide for example hotlines where they get asked different challenge questions and need to execute one extra step to restore their access.

Why Organizations Need to Prioritize Passwordless

Since secrets never leave the device in case of FIDO2, it's much harder for attackers to extract the secrets and use them.

>[!NOTE]
>While most passwordless compatible devices are secure, this doesn't mean that side channel attacks are impossible. For instance, during testing, NinjaLab found a vulnerability (EUCLEAK) in the cryptographic library that made it possible for them to clone the key. Yubico advised users to either upgrade or purchase newer, patched version of Yubikeys.

Transitioning the organization to passwordless standards requires both technical expertise and most importantly the backing of leadership and dedicated effort when it comes to dealing with legacy systems. Quite often, organizations would try instead to deprecate incompatible systems in favor of building or buying licenses for compatible ones.