Chris Farris

IBM said it clearly in 1979: a computer can never be held accountable, therefore a computer must never make a management decision. In 2026, we give those computers production credentials, customer data, and the ability to execute at machine speed,without solving the accountability problem first.

This is about what that means architecturally. Chatbots are wrong and humans decide what to do about it. Agents are wrong and then act on it. Behavior-level guardrails don’t survive contact with inference costs. Safety lives outside the model – in eight specific controls: scoped identity, data classification, IAM that enforces the laws, one-way doors that require human hands, and tamper-evident audit of everything the agent touches.

Wendy Nather coined the Security Poverty Line in 2011. Fifteen years later, the field still thinks in binary — haves or have-nots, the cyber 1% or everyone else. That leaves the entire middle invisible: a Security Upper Middle Class that mostly just shows up to BSides and gets back to work, and a Security Valley of Death that’s the most populated tier in the industry and the least discussed. This post builds a five-tier model by mapping economic class theory onto security maturity — and borrows Michael Green’s Valley of Death framing to explain why mid-market programs keep failing despite real investment.

This is mostly research from Claude, but reflects my framing of the issue

We have decades of experience with how we give an EA access to an executive’s life. And the entertainment industry is rife with stories of managers taking advantage of celebs by gaining access to their bank accounts and other aspects of their lives. All of this has made me realize that:

GenAI Threat management is just Insider Threat management, but faster and at scale.

Early next year, AWS will launch one of the largest changes to its cloud product in decades. For the first time, they will launch a new partition, the European Sovereign Cloud (ESC), open to anyone. This article covers why you might want to use it, what are some of the threats to consider, mitgations, and alternatives to consider.

This will be the first re:Invent I’ve missed since 2015 (we don’t talk about 2020 - never happened - FAKE NEWS), but I’ve relocated to Portugal and, for various reasons, had to miss skip it this year. Normally, I do a pre:Invent post on Thanksgiving morning as a prep for what I want to ask about, but this year it’s a summary of both pre:Invent and re:Invent.

pre:Invent also started late this year. We really didn’t start to see any interesting announcements till mid-November. In previous years, I’ve seen pre:Invent start in early October. The number of keynote announcements was pretty disappointing, too; a few things were thrown in as a “shot clock” at the end of a GenAI-laden keynote.

I’m shocked that laying off tens of thousands of people and replacing them with GenAI has slowed innovation.

Once again, I’ve categorized the announcements into a handful of categories focused on the ones that matter most for security practitioners and cloud governance folks:

• Security Features
• Cloud Governance & Costs
• Serverless Stuff
• GenAI & Bedrock
• And the other random stuff

A brief primer on how to think about threat modeling GenAI applications.

With the US Government acting in an erratic and hostile manner towards its traditional allies, it makes sense for companies not typically subject to US Jurisdiction to reconsider their threat models when using the big three cloud providers. All of them are US-based companies, and all three conduct a substantial amount of business with the US Government.

I’ve spoken a lot about Security Invariants, but all of them have been implemented using Organizational Policies. That’s great, but organizational policies don’t apply to the Organizational Management Account (aka “payer”). So how does one implement invariants in a payer account?

AWS would tell you that you shouldn’t be giving anyone access to the payer account, so the need for invariants should be minimal. However, that doesn’t reflect the reality that AWS never protected its customers from themselves and prevented the enabling of Organizations or Control Tower in an account with existing workloads. I would say this is a failure of Customer Obsession and demonstrates Security is not the Top Priority. AWS would hide behind shared responsibility and blame the customer.

Regardless, there are many cases where workloads are in a payer account, and as a security person, you need to live with those workloads while protecting the rest of the AWS Organization. So, how do we build invariants into a payer account when SCPs and RCPs don’t apply?

Enter Permission Boundaries.

I’ve finally settled on the wording for Farris’s Three Laws of Cloud Security Auto Remediation:

• A bot must never harm stateful data or allow stateful data to come to harm.
• A bot must act with utmost haste so functionality doesn’t become dependent on a misconfiguration.
• A bot must announce its existence and tell a carbon-based life form what it did and why.

I think these reflect the key tenants of auto-remediation while staying true to the original source of the Three Laws.

In previous posts, I took AWS to task for not making the customer’s security Job Zero. This offended some sensibilities, so let me lay out my 95 13 Thesis against the current AWS Culture and how it is neither Customer-Obsessed, nor makes security job zero.