THE ECHO

One story. Gone deep.

For six weeks I told founders how to decide which AI bets they could survive getting wrong. The same question kept coming back, and it is the one I would have asked. What do you use, and how do you govern it?

Here is the whole answer. It is not the clean version.

I run an AI assistant with read access to my entire working directory. All of Echo Cyber is in there. Strategy documents, my tax records, arguments I abandoned half-finished, who I am talking to and what I think of them. And one folder for a client engagement. That folder holds a draft statement of work and the reconnaissance I ran on their domain before the first call. Their DNS records, their certificate history, the subdomains they have published, what their infrastructure shows the internet. The assistant can read every byte of it.

Their actual documents are not in there. Those live in an encrypted exchange on separate infrastructure, and the assistant has no credential, no mount, no path. That is not a rule I wrote down. It is a system it cannot reach.

So that is the bet. Now the reasoning, which is the only part worth anything.

The reconnaissance is public-source. Every piece of it is something a stranger could have collected in an afternoon, because that is exactly how I collected it. If it leaked tomorrow, published information would become published again. The statement of work is commercial. Pricing, scope, dates. A leak there costs me a negotiating position and costs the client nothing that touches their security.

The material that would actually hurt them, the things they handed me because they trusted me, never enters the directory at all. That is the one bet I refused to take. It is also the only reason the rest of it is defensible.

Now the part I like less.

I made that architecture decision once, quietly, on an ordinary weekday. Nobody approved it. Nobody has looked at it since. It is the exact shape of the thing I have spent six weeks describing to other people.

There is a second one. My working notes get summarized by a hosted model so I can search them later. Those notes have real people in them. Prospects, partners, someone who did me a favor in March. I did not sit down and decide that. It came with the tool, and I noticed afterward.

I also keep saying I will move more of this onto hardware I own. Some of it already runs there. The search index that makes my notes findable is computed entirely on a machine in my house, no API call, nothing leaving the building. The rest of that plan has been six months from finished for six months. That is not a policy. That is an intention, and I would flag it as one if I found it in your company.

All of that is still true this morning. I am telling you because a policy you cannot check is a press release.

Here is what I think the real test is. Most AI policies are written to be shown. You can tell, because nothing in them refuses anything specific. Mine refuses exactly one thing, and it refuses in the only language that holds up under pressure. Architecture. My client's confidential material is not protected by a sentence I wrote. It is protected by an absence of credentials.

If the entire enforcement mechanism behind your AI policy is a paragraph in a PDF, you do not have a policy. You have a document. The difference shows up the first time somebody is in a hurry.

SIGNAL CHECK

What else matters this week.

The Reach Was a Default Setting

If you outsource your IT, something happened this month that is yours, and there is a decent chance nobody has told you about it.

N-able makes a platform called N-central. Managed service providers run it to administer their clients' machines, which means yours, if you have an MSP that uses it. On July 31 N-able's own monitoring service picked up unusual activity inside a customer's environment and found somebody actively exploiting a flaw nobody knew about. Huntress confirmed exploitation in the wild within two days. CISA added it to the catalog of vulnerabilities under active attack on August 3 and gave federal agencies three days.

The interesting part is not the flaw. It is what the flaw reached.

Once inside, the attackers did not need to escalate or break anything further. They used a feature. N-central ships with a remote access tool called Take Control and a default account that can drive it. That combination is designed to reach every machine the platform manages. So they used it as designed, walked into managed endpoints, went looking for domain controllers, moved sideways, and left tunnels behind to get back in.

Nobody chose that reach. Nobody sat in a room and decided this platform should be able to touch every endpoint in every client, from one login, by default. It arrived switched on because that is what the product is for.

One more thing worth your attention. The flaw under attack is an incomplete fix for an earlier flaw. The first hotfix shipped August 2. A second one, which N-able says "supersedes Hotfix 1 with additional hardening measures," shipped August 6. As of August 10 the attacks are still running and N-able is still expanding its protections while it watches the attackers change technique. Three rounds of "handled" in one week, and the company says it is not calling the investigation closed until it is fully confident.

You are not going to patch this. Your MSP is. What you can do takes one email and two questions. Do you run N-central on-premises, and are you on 2026.3.1.10? A straight answer to both tells you something much bigger about whether anyone over there is reading their own alerts.

THE NOISE

Not every signal needs action.

The Summer of the AI Incident Statistic

Somewhere in your feed this week is a number about how many companies have already had a security incident caused by an AI agent. It is large and frightening. There have been several this summer, they do not agree with each other, and they spread faster than anything that would let you check them.

I went looking for one solid enough to put in front of you and could not find it. The ones I could trace came from companies that sell the remedy. That does not make them wrong. It makes them unaudited marketing, which is a different thing from evidence, and you should not run a budget conversation on it.

The test is quick and works on any statistic, not just these. Who published it, and what do they sell? Is there a method note saying who was asked, and how many? And does the headline number match what the method actually measured, or has "reported an incident involving an AI tool" quietly become "was breached by an AI agent" somewhere between the survey and the headline?

Two of those three fail most of the time. You do not need the number anyway. You already know whether anyone in your company could tell you what your AI tools can reach, and that answer is free.

ONE QUESTION

No answer. Just the question.

What can your AI reach this morning that nobody ever decided to let it reach? Not what your policy says it can reach. What it can actually get to right now.

No link this week. This one is ten minutes and a sheet of paper.

List every AI tool anybody in your company has connected to something that matters. The inbox, the CRM, the code, the file store, the calendar. Beside each one, write who decided to connect it. Not who set it up. Who decided.

The blanks are your policy. Everything else is documentation.

Prefer audio? Jane reads every Pulse edition on the Signal vs. Noise podcast. Five minutes, same signal, no scrolling. Find it wherever you listen.

Michael Faas is a fractional CTO/CISO who translates technical complexity into business decisions. echocyber.io