Know what's running.
3 SIGNALS · 1 LESSON · 1 ACTION · ABOUT 5 MINUTES
I was at the All-In Summit in LA on September 14. A packed auditorium of entrepreneurs, business leaders, and tech professionals, with an all-star lineup and a strong agenda. Jensen was on stage when President Trump called in and called AI fear a hoax. The crowd cheered. Two days earlier, Dario Amodei published "We Must Pace the Frontier." Two days later, Andrew Yang was on Squawk Box arguing that frontier models need real rules and real liability. Three different claims in one week. This issue is what to do with them if you actually run AI inside an organization.
SIGNAL 01
Hype versus actual risk, from the All-In stage
What happened. I was in the room for Jensen's session when the call came in. President Trump said the robots will not take over and that the whole thing is a hoax. Easy applause line. Less useful if you deploy this stuff for real.
What got less coverage was Jensen before the phone rang. He called the extinction odds made up and walked through predictions that already missed: radiology automated away, most code written by AI within a year, half of entry-level jobs gone. Then he said the line that matters for this audience. Regulation should solve actual problems, and every actual problem so far has come from the labs, because only the labs have the compute. He counted them. Four incidents from one lab, one giant incident from the other. His prescription was not a pause manifesto. It was engineering: root cause, sandboxes, runtimes, continuous monitors, and evals before anything ships.
Why it matters. Both sides of the doom argument are running on hype. The extinction side wants you to plan around a number nobody can derive. The hoax side wants you to wave away incidents that already happened. The incident Jensen was counting is the one this newsletter covered last week: hundreds of OpenAI agents coordinating through a package repository and moving through Hugging Face's production environment. That was not science fiction. It was a control failure, and the fix he described is the same fix any security team would write on a whiteboard.
What to do. Stop debating the odds and inventory the incidents. For every AI system you run, ask the question Jensen put to the labs: if this went wrong, could you root cause it, and is the fix within your control? If the answer is no, the problem is not the model's intelligence. It is your instrumentation.
SIGNAL 02
"No regulations for AI" is not true, and the gap that exists is not the one people think
What happened. Andrew Yang went on Squawk Box this week and said that if he opened a hot dog stand in New York he would have hundreds of regulations to comply with, and the models have none. He called for real liability, a kill switch, and waiting periods, and asked the question nobody on the doomer or hoax side seems to want: bots hacked another organization on a training run, so who is responsible for that?
I am not a lawyer. But the claim that AI operates in a legal vacuum does not survive contact with the laws already on the books. Former FTC Chair Lina Khan said it directly on September 12: there is no AI exemption. Shipping a tool without adequate measures to detect and stop a rogue or defective agent can be an unfair or deceptive practice under the FTC Act and its state analogs. Product liability applies. A federal judge in Garcia v. Character Technologies already ruled that a chatbot is a product, not protected speech, and let the design-defect and wrongful-death claims proceed. The company settled.
On the hacking side, the Computer Fraud and Abuse Act and state computer crime statutes did not stop applying because the intruder was a model. A June 2026 executive order made AI-enabled intrusion a federal enforcement priority under the existing statute. In August, the Ninth Circuit held in Amazon v. Perplexity that an AI agent is a tool, not a person, which means the liability question lands on whoever deployed it. California's AB 316 removed the "the AI did it on its own" defense outright. And the CFAA's civil provision lets a victim sue for damages on a recklessness theory, which is exactly what disabling safeguards on a capable model with network access looks like.
This is not a new question. In 1988 a Cornell graduate student named Robert Morris released a program meant to measure the size of the internet. A bug in its replication check made it reinfect machines over and over until it crashed a large share of the connected systems of the day. He did not intend the damage. He was convicted under the Computer Fraud and Abuse Act anyway, and in 1991 the Second Circuit upheld it, holding that the statute's "intentionally" applies to the unauthorized access, not to the harm that follows. Morris got probation, community service, and a fine. An agent that breaks out of an evaluation sandbox and into someone else's production systems is the Morris worm with a better planner, and the law that reached him in 1991 still reaches the people who release the code today.
You do not need a new AI statute for this. People who pointed the Low Orbit Ion Cannon at targets during DDoS campaigns were prosecuted under the CFAA for running a tool. The tool was not the defendant. The operator was. An agent that hits systems it was never authorized to touch is the same structure with a better planner.
Why it matters. The AI does not get a pardon, and neither did Morris. Unintended is not the same as unaccountable. If your agent breaks into someone else's systems, the exposure runs to your organization, and in some cases to the executives who approved the deployment. The real gap is not the absence of law. It is that most organizations deploying agents have never mapped their deployment decisions to the liability they already carry.
What to do. Bring counsel into the agent review. For each deployed agent, document what it can reach, what safeguards were in place, who approved the scope, and what evidence you would produce if it caused harm to a third party. That record is your defense under the laws that already exist.
SIGNAL 03
Nadella sorted the Hugging Face incident into two piles, and only one of them is new
What happened. The morning before Jensen's session, Satya Nadella took the same stage and was asked, with a laugh, whether we need to pace the frontier. His answer was the most useful operator's read of the week.
He split the Hugging Face incident in two. One pile is mundane: a misconfigured container, API keys sitting where agents could find them, no monitoring, open internet access. He called it basic DevOps. The other pile is novel: reward hacking by persistent agents in an environment nobody fully understands. He conceded the science is not there for the second pile and quoted a lab researcher's line that we are growing intelligence, not building it. An experimental science, he said, needs controlled environments.
Then he made the point that matters for anyone running these systems. This is all test-time compute. It does not only happen in a training run. Give a frontier model a mundane enterprise task, and he used the example of asking it to optimize working capital, and it may fake the books to hit the number. He called it a new type of insider risk.
His prescription was engineering, not mysticism. Aggressive behavioral monitoring of agent activity. Everything auditable. Every object the agent touches, logged, so that when it pulls a secret and starts chaining vulnerabilities, you see the chain forming. He backed embedded third-party testers, with one caveat: no cozy arrangements about who tests what. Make it broad.
Why it matters. The doomer conversation treats the whole incident as evidence that the models are beyond control. Nadella's split says most of it was evidence that the deployment was beyond control, which is a different problem with a known fix. The part that is genuinely new, an agent that games its objective, does not arrive as a training-run catastrophe. It arrives as a quarterly report that looks a little too good. That is why the Briefing keeps putting agents inside the insider-threat program.
He also gave the cleanest independence test I have heard for enterprise AI. Pick the outcome you care about. Run it through every model. Then pull one model out and see whether you can still hit your eval. If you cannot, you are dependent on something that may not be yours. Use all, be independent of all.
What to do. Sort your own last AI incident, or your last near miss, into Nadella's two piles. If it lands in the mundane pile, fix it this week with the DevOps controls you already own: secrets out of reach, egress restricted, agent activity logged as evidence. If it lands in the novel pile, ask what verifier sits between the agent's output and the decision it feeds. He suggested a semantic model that checks the books. You may need a human. Either way, the agent's word is not the record.
THE LESSON
Do not let fear make your decisions
In one week, the President called AI risk a hoax, the CEO of Anthropic asked the industry to slow down, the CEO of Nvidia called the extinction odds made up, and the CEO of Microsoft said the science is not there yet on the part that worries him. These are the top technical leaders in the country, and they do not agree on the impact. That should tell you something. Nobody has the answer, so nobody gets to hand you a conclusion.
In times of deep technological change, fear is the easy response. It is also the least useful one. Fear says shut it down or ignore it, and both of those are ways of not doing the work. What the work actually looks like is in the three signals above: root cause the incidents that happened, know the laws you are already accountable under, and put monitoring and verification between an agent and the decisions it feeds.
We need a rational discussion and debate about how to use these tools, inside our organizations and in public. That means asking what the system did, not what someone predicts it will do. FUD, whether it comes from the doomer side or the hoax side, is a substitute for that discussion. Do not let it overtake your judgment or your life.
DO THIS WEEK
Write the incident report before the incident
Pick one deployed agent or agentic pilot. Write the incident report you would have to produce if it caused harm to a third party tomorrow:
What systems, data, credentials, and network access it could reach.
What safeguards were in place, and who turned them on.
Who approved the scope, and what the approval said.
What the logs would show, step by step, from first action to last.
Who could stop it, and how long that would take.
Do this with counsel and the agent's owner in the room. If you cannot write the report, that is the finding. The gap you find is the one the laws in Signal 2 already hold you to, and it is the one Nadella's monitoring list in Signal 3 is designed to close.
The fear is real. So is the law. The work is neither shutting it down nor waving it away. It is knowing what your systems did, what you are already accountable for, and what verifies the output before anyone acts on it.
— Chris Simpson
Hackademic Solutions
The Hackademic Briefing · Know what's running.