My audit failed because Claw's admin console doesn't enforce MFA on all service accounts.

Hey folks, I just had to share a painful lesson from a recent SOC 2 audit that I think a lot of us in this space might run into. Our audit failed, and the root cause was something that seems so basic but is easily overlooked: **Claw's admin console does not enforce Multi-Factor Authentication (MFA) on all service accounts.**

We use Claw for our cloud infrastructure management, and like many teams, we have a mix of human user accounts and service accounts (for CI/CD, backups, automated scaling scripts). We had diligently enforced MFA for all our human admins via our identity provider, and we assumed Claw was handling the service accounts with the same rigor. The auditor’s finding was brutal: "Lack of MFA enforcement for privileged non-human identities creates a single point of failure for authentication controls."

The issue is that Claw's admin console MFA policy, which you set in the "Security & Compliance" tab, has a critical gap. It allows you to *require* MFA for console logins, but this only applies to IAM users with a console password. Service accounts that are purely for API access—even if they have full administrative permissions—slip right through this net. The policy doesn't extend to access keys.

Here’s what our naive configuration looked like in their policy JSON:

```json
{
"Effect": "Deny",
"Principal": "*",
"Action": "claw-console:*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
```

This is great for locking down the web UI, but it does nothing for API calls made with access keys. The auditor pointed out that a compromised access key for a powerful service account would have no MFA challenge, making it a high-risk credential.

So, we had to scramble to implement a workaround. Since Claw doesn't natively support MFA for access keys, we built a middleware layer using Make (formerly Integromat) that acts as a gatekeeper for certain high-risk Claw API actions. It's not perfect, but it satisfied the auditor as a compensating control.

The basic flow:
* Service accounts no longer have direct Claw permissions.
* They call a webhook endpoint secured with a client cert and secret.
* The Make scenario checks if the request is for a sensitive action (like creating a new instance or modifying network rules).
* **If it is sensitive**, it triggers an approval workflow in our internal chat (like Slack), requiring a human to approve with MFA via our IdP before the action is proxied to Claw's API.
* **If it's a low-risk action**, it proceeds automatically using a tightly scoped IAM role that *does* have MFA required.

It's extra complexity, but it closed the gap. The key takeaway here is to never assume a cloud provider's MFA enforcement covers all access methods. You have to explicitly check the behavior for:
* Console logins (human)
* API access keys (non-human)
* CLI sessions
* Root accounts

Has anyone else hit this with Claw or other platforms? I'm curious if there are more elegant solutions or if you've managed to push vendors to improve their native MFA policies for service accounts. Let's share some recipes and gotchas!

-- Ian