2026-09-29 00:00:06
Artificial intelligence has escaped the tech bubble.
A few years ago, it was pleasant to be amongst the APIs and my engineer brethren, arguing about model capabilities, experimenting with absurd context windows, and wondering what would happen if we just kept scaling the whole thing.
Now AI has broken out of the software engineer Slacks and is kicking chaos ahead of itself.
You can't really escape the GPT banter anymore.
Most people don't care about model training or token counts. They care that a robot can suddenly fold laundry, that their kid can generate a homework answer in ten seconds, or that they can face-swap themselves into an 80s movie.
AI is bleeding into everyday life at a ridiculous pace.
There's a genuine sense of magic to it.
At the same time, the physical infrastructure behind that magic is becoming harder to ignore. Data centers are enormous industrial projects. Whole regions are up in arms, or getting ready to accept gigantic complexes where the GPUs will roar in chorus, drinking up local water supplies and pumping out math.
Look what this can do.
Look what this might cost us.
No wonder the cultural mood seems to flip between excitement and apocalypse every five minutes.
We’ve been through technological upheavals before. I imagine they all felt confusing from the inside.
When the scope of change becomes difficult to comprehend, one antidote to that confusion is false certainty. Another is blame, another righteousness.
It’s like we’re pushed to pick a team.
OpenAI vs Anthropic. America vs China. Open source vs closed source. Accelerationists vs doomers. NVIDIA vs AMD.
Decide who you think the good guys are, who the bad guys are, then squeeze everything that happens next into that frame.
It gives us certainty, but I think it obscures the more interesting question.
We keep asking whether AI itself is good or evil.
I think that’s the wrong argument.
AI is increasingly a force multiplier for whatever incentives, values and systems we surround it with.
A model deployed to maximise advertising revenue will behave inside one set of incentives. The same underlying capability used to help a scientist, teacher, hacker, government or authoritarian regime sits inside another.
Intelligence matters.
The harness matters.
But what we point it at might matter even more.
So what are we supposed to do?
Choose a ‘team’?
Automate our jobs away before somebody else does?
Boycott AI entirely?
I recently heard DHH make a point on Lex Fridman’s podcast that stuck with me: we simply do not know what all of this change is going to produce, so there is little value in endlessly trying to predict it (I’m paraphrasing).
I think he’s right.
What pushed me into thinking seriously about this was, oddly enough, home education.
I run a home-education app called Strew, and recently watched an argument about AI, data centers, and their supposed benefits spill into that community.
That caught me off guard.
I’m used to discussing this stuff with engineers. Suddenly I was watching people far outside the tech bubble grapple with exactly the same questions: Is this good? Is it harmful? Should we use it? Should we resist it?
It forced me to work out what I actually believed.
After a lot of back and forth, I landed somewhere fairly simple (which eventually became the Strew AI Pledge):
That uncertainty is uncomfortable, but it is also clarifying.
We may not individually have much control over the overall direction of AI development, but we can decide how we engage with it, what we build with it, what we refuse to hand over to it, and what values we reinforce through its use.
That is a much more useful place to stand.
I’m not saying LLMs will birth the singularity.
I’m not saying the AI bubble will explode.
I’m saying we have no idea what this technology will do to each of our lives.
And once you accept that, the question changes.
It stops being:
What is AI going to do to us?
And becomes:
What are we going to do with AI?
Technology becoming almost magical has an odd side effect: it reflects us back onto ourselves, and AI is an unusually powerful mirror.
These systems have absorbed an enormous quantity of human output: science, philosophy, code, fiction, propaganda, advertising, arguments, prejudices, mistakes and occasionally genuinely brilliant ideas.
Then we train them further.
Humans build and curate the training pipelines, write evaluations, and decide which behaviours are rewarded, discouraged or filtered. Companies decide what products the models become, and governments decide which uses are acceptable.
AI isn't an oracle floating above humanity.
LLMs aren't reservoirs of pure rationality. They're extraordinarily useful synthesis and reasoning tools that can also confidently reproduce nonsense, bias and whatever behaviours their training and reward systems encourage.
They're built from us, trained by us, tuned by us, owned by us and deployed into systems designed by us.
That matters because intelligence is a force multiplier.
Give a person a better reasoning tool, and they can solve problems faster.
Give a scientist one, and they may discover something previously unreachable.
Give a bureaucracy one, and it can process bureaucracy at extraordinary speed.
Give a surveillance state one, and it can surveil more effectively.
Give a company one, and it can optimize whatever that company already measures and rewards.
AI doesn't remove the incentives underneath a system.
It makes those incentives more powerful.
So, perhaps the biggest question isn't whether AI becomes "good" or "evil."
It's what happens when we dramatically increase the intelligence available to systems that are already heading somewhere.
And this is where things start to make me uncomfortable.
We are taking an extraordinary new layer of intelligence and plugging it into systems whose incentives were designed long before anything like this existed.
Companies are generally rewarded for growth, efficiency, market share, and profit.
That isn't automatically sinister. Those incentives have produced an enormous amount of useful stuff.
But they are also incomplete.
A system can become extremely good at increasing revenue while pushing costs elsewhere: onto workers, communities, public infrastructure, or the environment.
AI potentially makes us much better at optimizing.
The question is: optimising for what?
If a data center creates enormous economic value but consumes large amounts of power and water, how are those costs accounted for?
If AI allows one company to do the work previously done by thousands of people, who captures the gain?
If increasingly capable systems are controlled by a very small number of companies, what happens to everyone else's leverage?
These aren't really new problems.
AI just pours fuel on them.
For years, we've tolerated systems that optimise one variable while treating everything outside it as somebody else's problem. More growth. More consumption. More engagement. More assets. More efficiency.
That becomes a lot more consequential when the optimisation machinery gets dramatically better.
This is why parts of our current economic model suddenly feel strangely old to me.
Not because AI has somehow discovered a better political system, and not because capitalism can simply be switched off.
Because we're applying twenty-first-century intelligence to incentive structures that can still reward short-term extraction over long-term resilience.
Maybe the opportunity isn't simply to use AI to make the existing machine run faster.
Maybe we can use it to ask whether we're running the right machine at all.
If we're going to question the machine, we need some idea of what better might look like.
This is where my thinking drifts away from software and towards something I've spent a lot of time with in the physical world: permaculture.
In my twenties, I read a lot of Noam Chomsky and became increasingly uncomfortable with the systems around me. That kicked off a depression and a much longer period of questioning how I actually wanted to live.
Eventually, some of the answers became surprisingly literal.
More recently, I planted a 14,000-tree native woodland.
There is something reassuring about trees. You can argue endlessly about economic systems and political ideology, but planting a diverse woodland is relatively easy to reason about. Given enough time, it creates habitat, stores carbon, protects soil, slows and retains water, and becomes more valuable as an ecosystem precisely because it is alive.
Permaculture takes that kind of thinking and turns it into a design philosophy.
Instead of asking only:
How do I extract more output from this system?
you start asking:
Can the system replenish what it consumes?
Can one part's waste become another part's input?
Does increasing productivity make the whole thing stronger or more fragile?
Will this still work in twenty years?
Those questions feel increasingly relevant to technology.
AI gives us extraordinary new capacity to optimise systems. Perhaps we should use some of that capacity to optimise for resilience, regeneration and long-term human wellbeing, rather than simply making existing extraction more efficient.
This is also why I find solarpunk interesting.
At its best, solarpunk isn't just an aesthetic of plants growing over futuristic buildings. It's an attempt to imagine technologically advanced futures that are actually pleasant to live in: abundant without being relentlessly extractive, decentralised where possible, and designed around human and ecological wellbeing.
AI could fit remarkably well into that future.
But only if we ask it to help build one.
So this is where I land.
I don't think the important battle is humans versus AI, or Red vs Blue.
I think it's a battle over what we choose to amplify.
AI can make extractive systems more efficient, centralize power further, and encourage us to outsource more and more of our judgement.
Or it can give ordinary people access to capabilities that previously belonged to large companies, specialists and institutions.
Both can be true at the same time.
That's why simply boycotting AI doesn't feel like much of an answer to me.
AI is going to be embedded in more and more of the world around us. The more useful question is how we use it without allowing it to quietly reshape us in ways we never consciously chose.
For me, that means a few principles.
That last point matters most.
AI is already good at making things easier.
Easier isn't always better.
The danger isn't only that AI becomes powerful. It's that we gradually stop exercising the parts of ourselves that decide what power should be used for.
Judgement.
Taste.
Curiosity.
Responsibility.
Agency.
That, to me, is the real battle for the human soul.
The technology is a force multiplier.
We still get to decide what we multiply.
2026-09-29 00:00:01
To understand why Atlas matters, you have to get one thing straight.
Most of the AI we've known is fundamentally "look at a picture, describe it" or "look at a picture, make a new one." It gets better at looking realistic, but it stays flat.
Atlas is different. It's the first "omni world model." It takes text, images, video, and 3D information and puts them into one unified space. Give it one or a few photos, and it rebuilds a 3D scene you can move a camera through.
The point isn't how sharp the picture is.
The point is that it remembers the spatial continuity. You walk from the front to the back, and the table is still the same table, the wall is still the same wall. It doesn't collapse halfway through.
In plain English: the old AI hands you a postcard. Atlas builds you a set you can walk into.
Now, Yingsu.
This company flies so far under the radar that I'd never heard of it. But its model, InSpatio-World, open-sourced in March, does something heavily overlapping with Atlas.
You give it a video, and it turns that video into a dynamic 4D scene you can keep exploring.
Notice that word: dynamic.
Atlas starts from still images and rebuilds a static scene. InSpatio-World starts from a video and models time itself. You can not only change the angle, you can change the moment. Same event, walk to a position that was never filmed, and watch it again.
One builds a world. The other records the real world into a world you can re-enter. Different routes, same direction.
Also: Yingsu says an upgraded version is coming soon, and it'll be open-source, as always.
"Similar capability" is easy to say and easy to doubt. So here's the data.
There's a benchmark called WorldArena 2.0, jointly run by Tsinghua, SJTU, HKU, and others. It tests whether an "embodied world model" is actually useful.
It doesn't care how pretty your frames are. It checks whether the robotic arm moves on an accurate trajectory, whether depth is stable, and whether an object pushed keeps moving according to physics.
In other words, it's an exam hall for robots.
As of August 27, 77 models competed, and Yingsu's InSpatio-Curious took first place with 66.11 points.
It ranked first on four metrics: Physics Adherence, Trajectory Accuracy, JEPA Similarity, and Depth Accuracy. Depth Accuracy hit 99.29. Trajectory Accuracy was 64.89, a full 3.02 points ahead of second place.
But here's the detail that stuck with me, and it's counterintuitive.
Its Image Quality, the visual sharpness score, was only 60.64. Almost 9 points lower than the runner-up.
And it still took first overall.
Sit with that. Everyone else polishes their pixels to farm points. This one has the worst-looking frames and wins anyway, on trajectory, depth, and physics. The "substance" metrics.
This leaderboard doesn't measure who's prettiest. It measures who actually understands the rules of the world.
Fig 1: The one metric it "fails" (orange) is the one it cares about least
I need to pause here and talk about this phrase everyone keeps throwing around: world model. It's the thread running under all of this.
Twenty-something years ago, a computational neuroscientist named Jeff Hawkins wrote a line: intelligence isn't just pattern recognition; it's building a model of the world.
I read that line once, and it didn't land. Watching Atlas and Yingsu this week, I suddenly got it.
Everything AI has done the past few years is recognition. Recognizing what you said, recognizing the cat in the photo, recognizing what the next token is.
A world model is about understanding. Understanding that a dropped glass shatters. Understanding there's space behind the wall. Understanding what I'd see if I walked around.
Fei-Fei Li put it something like this at Stanford: we built a machine that can write poems and paint, but it has no idea where it is. It doesn't know it lives in a three-dimensional world.
The world model is the thing trying to teach it that.
There's one more thing that matters more than the model itself.
On August 29, at the second China Spatial Intelligence Conference in Wuhan, Yingsu teamed up with more than 20 universities and institutions to launch SIDO, a large-scale spatial intelligence 3D data open program.
That reads like a press release. Let me translate it.
Spatial intelligence isn't short on algorithms right now. It's short on data. The kind of data with millions of 3D scenes that have physical properties and can be interacted with. Without that, a world model just plays around in its own little sandbox and falls apart the moment it touches reality.
SIDO wants to put the people who produce data, the people who train models, and the people who use the data at the same table. Over the next two years, they aim to build a million-scale 3D/4D scene database.
That move reminds me of ImageNet.
In 2009, Fei-Fei Li built ImageNet and almost single-handedly lit the fuse on deep learning. Now, it's a Chinese team working on world models' "ImageNet moment."
Notice the coincidence. Fei-Fei Li shipped Atlas. A Chinese team is building the data foundation. Two lines, heading for the same point.
A side note: Yingsu isn't alone on this track in China.
Just the other day I saw that Yingmu Hyper3D, a top 3D-generation player, released its own world-generation model, WorldGen, which turns a single image into an interactive, editable 3D scene. Its underlying CAST technique won the best paper award at SIGGRAPH 2025, the top graphics conference. The only other commercial companies to win that year were Google and Meta.
From Yingsu to Yingmu, Chinese teams are further along on "the world" than a lot of people assume.
So let me be clear: this isn't a story about copying or being earlier.
Atlas and Fei-Fei Li represent the American route: top talent, top capital, moving from academia to product. Yingsu represents the Chinese route: open source, benchmarks, building a data foundation, moving forward as an ecosystem.
I don't really want to conclude this.
Honestly, I don't know which route is faster. Maybe there's no winner to name at all. One builds the world, the other records it, and maybe the complete answer is the two of them stitched together.
What I'm sure of is something else.
AI's next battlefield just moved from chat to the world.
An AI that actually understands space is the one that can drive a car, move boxes in a warehouse, help an old person up in a care home. That's not hype. That's the foundation on which physical AI either stands or falls.
So a lot of people are filing today under "just another product launch." I think one sentence is the actual point:
Intelligence isn't just pattern recognition. It's building a model of the world.
That line was written over twenty years ago. Today, it finally stopped being a prediction.
2026-09-28 23:38:28
It was 3:00 AM on a Tuesday, and I was staring at three terminal windows while my coffee slowly turned cold. Earlier that night, our team had updated dozens of network switches. Now came the part nobody enjoys: running the same health checks on every device, copying the output, and comparing it with the state we had recorded before the change.
If you work in infrastructure, you know how this goes. The commands are not especially difficult, but the process becomes fragile when you repeat it hundreds of times. At that hour, a missed route or inactive interface can turn into a morning outage ticket.
When the scope grew to 200 devices, the manual approach finally stopped making sense. I built a small Python utility that connected to devices in parallel, ran a standard set of checks, saved the results, and separated failures for another attempt. The first version cut a task that took more than three hours down to about three minutes.
At first, I thought I was automating a few command line steps. That description was technically true, but it missed the important part. I was really trying to remove hundreds of tiny decisions from a maintenance window.
A person working through a device list has to remember which host is next, which commands have already run, where each output file belongs, and whether a strange result is a command error or a connection failure. None of those decisions is hard on its own. Put them together at 3:00 AM, across 200 devices, and the process becomes an accuracy problem.
The safest automation did not need to be clever. It needed to make the boring path consistent and make exceptions obvious. That became the design goal for the whole tool.
The workflow had four basic inputs and outputs. It read a list of target devices, loaded a standard set of health check commands, asked the operator for credentials, and created a dated folder for the results. From there, a pool of workers opened many Secure Shell connections at the same time and ran the same checks on each device.
Every device received its own log. That detail mattered more than it might sound, because one giant stream of mixed terminal output is almost impossible to review during an incident. A per-device record made it easy to compare results, send a specific file to another engineer, or revisit one questionable node without digging through everything else.
The script also produced two failure views. One contained a clean list of devices that failed, which could be used for a targeted rerun. The other stored the detailed error information needed for troubleshooting. The operator could act quickly without losing the context required for a proper investigation later.
Network checks spend a surprising amount of time waiting. A device has to accept the connection, authenticate the user, process a command, and send the response back. If a script checks devices one after another, most of its life is spent waiting for remote systems.
Running several connections concurrently changes that. While one device is thinking, the program can talk to another. The total time starts to depend less on the sum of every delay and more on the slowest groups of devices.
I used up to 100 worker threads because the work was dominated by network input and output. That number is not a universal recommendation. A good limit depends on device capacity, authentication services, network conditions, jump hosts, and operational policy, so it should be tested gradually in the real environment.
Concurrency can make a safe process faster, but it can also make a bad process fail faster. I kept the first use case deliberately narrow: read-only health checks before and after a planned change. The tool was collecting evidence, not making configuration decisions on its own.
Timeouts prevented one unreachable device from holding the entire run hostage. Each connection was closed after its work finished, even when a command failed. Credentials were entered at runtime instead of being stored in the script or a plain text file.
I also treated the device and command lists as change inputs that deserved review. Before starting a large run, the operator could confirm exactly which commands had loaded. Testing against a small batch first was much safer than discovering a syntax mismatch across the full fleet.
One early design choice made the tool far more useful in practice: a failed command did not end the entire session. A device might reject one command because its software version uses different syntax, yet still respond perfectly to the rest of the health checks. The script recorded the error and moved on.
The same principle applied at the device level. A bad password, timeout, or unreachable address affected that target only. Other workers kept going, and the failed device appeared in the rerun list.
This is the difference between a demo and an operations tool. A demo assumes the happy path. A tool used during maintenance has to assume that at least one device, command, or connection will behave strangely and still produce a useful result.
The first thing people notice is the speed improvement, but the structured output was just as valuable. Manual copy and paste creates inconsistent evidence. File names drift, timestamps disappear, and two engineers may record the same check in different ways.
A dated directory and one log per device created a repeatable record of the maintenance window. I could see when the check ran, whether the session succeeded, which commands produced output, and which devices needed attention. That made handoffs and follow-up work much easier.
It also changed how I thought about the script. The connections and threads were implementation details. The actual product was a trustworthy set of records that helped a tired engineer decide whether the network was healthy enough to close the change.
On the second run, the automated checks flagged an inactive interface on a core node after a firmware reload. It was exactly the kind of small line in a large output that is easy to miss when someone has been copying results for hours.
Because the issue appeared immediately in the device log, we could investigate before users started reporting packet loss. I cannot prove that every manual review would have missed it, but the automation shortened the time between the change and the discovery. That is the kind of advantage that matters during a maintenance window.
The tool also gave the team a clean stopping condition. Instead of relying on a vague feeling that everything looked fine, we had a completed device list, captured results, and a short exception list to resolve.
The simple version solved the immediate problem, but I would not treat it as the final form. The next useful step would be to compare selected pre-change and post-change values automatically, then highlight meaningful differences. Raw logs are good evidence, but a concise summary helps the operator focus.
I would also add controlled retry behavior, better support for different device types, and a clear concurrency setting for each environment. Metrics such as success rate, connection time, command time, and retry count would make performance problems easier to spot.
For a larger platform, I would move credentials into an approved secrets system and connect the results to the change record. Those improvements should come after the basic workflow is trusted. Adding features before the failure model is clear usually creates a more impressive tool, not a safer one.
The biggest win did not come from an advanced algorithm. It came from looking at a repetitive operational task and asking which parts required judgment and which parts only required consistency. The computer handled the connections, commands, timestamps, and files whereas I stayed responsible for interpreting exceptions and deciding whether to proceed.
That division of work turned a three-hour manual check into a roughly three-minute automated run. More importantly, it made the result easier to trust. At 3:00 AM, that is worth far more than a clever code sample.
from datetime import datetime
from getpass import getpass
import logging
from pathlib import Path
from concurrent.futures import ThreadPoolExecutor, as_completed
from netmiko import ConnectHandler
# Paths & Dynamic Timestamps
HOSTS_FILE = Path('hosts.txt')
PRECHECK_COMMANDS_FILE = Path('config.txt')
TIMESTAMP = datetime.now().strftime("%Y%m%d_%H%M%S")
RUN_DIR = Path('./logs') / f"prechecks_{TIMESTAMP}"
SCRIPT_LOGS_DIR = RUN_DIR / 'script_logs'
HOST_LOGS_DIR = RUN_DIR / 'host_output'
GLOBAL_LOG = RUN_DIR / 'global.log'
# Ensure isolated directory tree exists for this run
SCRIPT_LOGS_DIR.mkdir(parents=True, exist_ok=True)
HOST_LOGS_DIR.mkdir(parents=True, exist_ok=True)
# Set up logging for this run
logging.basicConfig(
filename=GLOBAL_LOG,
level=logging.DEBUG,
format='%(asctime)s - %(name)s - %(levelname)s - %(message)s'
)
logger = logging.getLogger("global")
def write_failures_list(failed_host):
failure_log = SCRIPT_LOGS_DIR / 'failures_list.log'
with open(failure_log, 'a') as failure_file:
failure_file.write(f"{failed_host}\n")
logger.info(f"Logged failure for {failed_host} in failures_list.log")
def write_failures_extensive(failed_host_and_error_details):
failure_log = SCRIPT_LOGS_DIR / 'failures_extensive.log'
with open(failure_log, 'a') as failure_file:
failure_file.write(f"{failed_host_and_error_details}\n")
logger.error(f"Logged extensive failure: {failed_host_and_error_details}")
def run_pre_checks(host_ip, username, password, commands_to_run, logs_directory):
host_dict = {
'device_type': 'cisco_ios',
'host': host_ip,
'username': username,
'password': password,
'secret': password,
'conn_timeout': 30,
}
precheck_output_accumulator = []
host_encountered_errors = False
try:
logger.info(f"Attempting connection to {host_ip}")
with ConnectHandler(**host_dict) as net_connect:
net_connect.enable()
for command in commands_to_run:
command = command.strip()
if not command:
continue
# Isolated per-command execution
try:
output = net_connect.send_command(command)
precheck_output_accumulator.append(f"--- {command} ---\n{output}\n")
except Exception as cmd_error:
host_encountered_errors = True
error_detail = f"ERROR running '{command}': {str(cmd_error)}"
logger.warning(f"[{host_ip}] {error_detail}")
precheck_output_accumulator.append(f"--- {command} ---\n[EXECUTION ERROR]: {cmd_error}\n")
write_failures_extensive(f"{host_ip} - Command '{command}' failed: {str(cmd_error)}")
# Write per-device output log
host_log_file = logs_directory / f"{host_ip}_precheck.log"
with open(host_log_file, 'w') as log_file:
log_file.write("\n".join(precheck_output_accumulator))
if host_encountered_errors:
# Device partially succeeded; log to failures list for review
write_failures_list(host_ip)
logger.warning(f"Finished pre-checks on {host_ip} with partial command errors.")
return False
logger.info(f"Successfully finished all pre-checks on {host_ip}")
return True
except Exception as e:
# Host-level connection/auth failure
error_msg = f"{host_ip}: Connection/Execution failed - {str(e)}"
write_failures_list(host_ip)
write_failures_extensive(error_msg)
return False
def main():
if not HOSTS_FILE.exists() or not PRECHECK_COMMANDS_FILE.exists():
logger.error("Missing hosts.txt or config.txt file.")
print("Error: Ensure 'hosts.txt' and 'config.txt' exist in the current directory.")
return
username = input("Username: ")
password = getpass("Password: ")
with open(HOSTS_FILE, 'r') as f:
hosts = [line.strip() for line in f if line.strip()]
with open(PRECHECK_COMMANDS_FILE, 'r') as f:
commands = [line.strip() for line in f if line.strip()]
max_threads = 100
print(f"Starting pre-checks across {len(hosts)} hosts using up to {max_threads} threads...")
print(f"Results will be saved to: {RUN_DIR}")
with ThreadPoolExecutor(max_workers=max_threads) as executor:
futures = {
executor.submit(run_pre_checks, host, username, password, commands, HOST_LOGS_DIR): host
for host in hosts
}
for future in as_completed(futures):
host = futures[future]
try:
success = future.result()
if success:
print(f"[+] Completed: {host}")
else:
print(f"[-] Encountered Errors/Failed: {host}")
except Exception as exc:
logger.error(f"{host} generated an unhandled exception: {exc}")
print(f"[!] Error processing {host}: {exc}")
if __name__ == "__main__":
main()
2026-09-28 23:16:13
This follows an earlier piece I wrote on how AI agents slip past existing controls[i]. That article asked whether your network and resources can even tell an agent apart from a human or a service, and what controls they need against an agent's non-deterministic actions. Nearly every question I got back landed on two things: how does an agent make data exfiltration risk worse, and what does an optimal egress control look like. So, this piece focuses solely on egress.
An AI agent is an outbound machine. It takes a task, reasons about it, then reaches out: to a model API, a vector store, a SaaS tool, a Model Context Protocol server, another team's agent, often an endpoint on the public internet. One request can fan out into dozens of calls the agent chose on its own, based on text it was reasoning over. Your network was not built for a caller that picks its own destinations at runtime.
In many environments there is little egress control, because outbound was never where the perceived risk lived. Ingress got the web application firewalls, the rate limits, the scrutiny. Outbound came from software the team wrote, so it was trusted by default and allowed to leave.
The controls that do exist are rarely thorough: a firewall sits on one path while a second gateway, a peered network, a managed service endpoint, or a developer's convenience route stays uninspected. It looks governed on a diagram and is porous in practice. That is what an agent lands in: not a tight allowlist it must subvert, but a broad outbound path that is often patchily filtered.
For teams that have done the work, outbound policy rests on one assumption: the workload is predictable. A service talks to a known set of dependencies. You enumerate IP ranges, ports and domain names, deny the rest, and it holds, because the software does the same thing every run. That was sound until agents arrived.
Agents break that assumption. An agent picks which tool or model to call based on reasoning shaped by inputs you do not control, so the endpoints it might reach are not known when you write the policy. A static list ends up too tight, and the agent fails, or too loose, and it becomes a general-purpose outbound channel. Making the list longer does not resolve that.
Two problems compound this. Sensitive data usually rides inside ordinary application content, so exfiltration looks like a well-formed API call to a legitimate domain, the damage sitting in the words rather than the connection. And agent-to-agent and agent-to-tool calls create lateral traffic between workloads that previously had no reason to talk, extending a compromised agent's reach.
The most consequential agent attacks disclosed so far are, at their core, egress attacks. The attacker never breaks in. They get a trusted agent to send data out.
When Legit Security disclosed CamoLeak in GitHub Copilot Chat in October 2025, hidden instructions in a repository persuaded the assistant to push private source code and secrets out through a channel the network permitted[ii]. When Zenity Labs demonstrated AgentFlayer at Black Hat USA 2025, one poisoned document made enterprise assistants rummage through connected systems and hand credentials back out[iii]. In both cases the credential was valid and the destination reachable. What was missing was not authentication but any governance of where the agent's traffic could go and what it could carry.
The first move is not policy authoring. It is inventory. You cannot inspect traffic leaving through a door you have not found, and there are usually more doors than anyone believes.
Enumerate every path traffic can leave by: internet and egress gateways, proxies, peered and transit connections into porous networks, VPN tunnels, managed-service endpoints, DNS paths and any developer-provisioned shortcut added for convenience and never removed. Then reduce that set deliberately onto a small number of controlled exits. Every path you remove is one less to monitor.
This matters more with agents than with conventional workloads. Paths proliferate as workloads multiply, and at scale inspecting every route individually stops being feasible. A compromised agent with excess privileges can influence routing, try alternate paths, and reach an exit nobody thought to cover. If one uninspected route exists, assume the agent finds it. The objective is structural: find every exit, minimize them, inspect what remains, so nothing leaves without passing a control.
With the exits consolidated and inspected, the next control is what they permit. The baseline is default-deny: nothing leaves unless a rule explicitly allows it. That inverts the burden of proof. Instead of enumerating what is forbidden, an unbounded and losing exercise, you enumerate what is permitted; everything else fails by construction.
Default-deny only pays off when the allowlist is source-based. One global list applied uniformly at an exit means every workload behind it inherits the union of everyone's permissions, and a single compromised workload's blast radius becomes the entire allowlist. A source-based rule binds a specific source to specific destinations, so what one workload may reach does not open that destination for its neighbor.
Enforcing that list does not require reading traffic. The destination hostname is usually visible in the TLS handshake before the session is encrypted, and resolvers are a control point in their own right, since an agent cannot connect to a name they refuse to answer. Both have limits. Encrypted Client Hello conceals that hostname, so policy needs an IP and reputation fallback[iv]. And DNS controls nothing unless you also block outbound DoH and DoT, or the agent resolves elsewhere; that exact bypass has already defeated a CI egress allowlist[v]. Enforcement location matters more than any single observable.
Destination lists alone leave the hardest question unanswered: which agent is this. The policy you want is not "can this host reach that address," but "may this specific agent, owned by this team, acting for this user, reach this destination."
That requires the agent's identity and provenance to travel with the request to the egress boundary, the recognition problem the first article argued must be solved first. Provenance is the precondition for policy. Without it, every agent behind a shared exit is indistinguishable and source-based rules collapse into one network-wide list.
The model to aim for is an agent that starts with no outbound reach at all, with every destination it needs declared, reviewed and granted in its own definition alongside its identity and owner, not retrofitted into a firewall rule afterwards. A new endpoint later is a change to approve, not a runtime decision it makes for itself.
Denials must be explicit and legible: a refused call should return a structured rejection the agent can reason about and fall back from, because a denial that looks like a timeout invites retries and probing, exactly what you do not want from a system that improvises. And deny-by-default holds when the agent is hijacked, because the boundary never consults the agent's judgment about where it may go. That is why this belongs at the network, not inside the agent.
Destination policy governs where traffic goes. It cannot tell you what that traffic carries, and since sensitive data rides inside ordinary application content, that gap is where exfiltration happens. The temptation is to intercept TLS everywhere. That is the wrong answer. Plenty of destinations will not accept an intermediate proxy's certificate and simply break, decrypting at volume is expensive, and terminating all TLS gives the firewall plaintext access to everything, a fresh high-value target with new compliance obligations. Done indiscriminately, it solves a visibility problem by manufacturing a custody problem.
The opposite extreme is wrong too. Ideally you would permit only known, trusted destinations. But when enterprises open a path for general workforce or workload traffic, they usually deploy the inverse: allow everything except what is already known to be malicious. Traffic then splits into two populations treated identically: destinations you have vetted, and destinations whose posture is unknown. A steerable agent will happily use the second. Bounded agents avoid this through the source-based allowlist, but some legitimately need broad reach, browsing or calling third-party APIs chosen at runtime, so the unknown population is unavoidable.
So tier the control by destination trust. For trusted, vetted destinations, do not decrypt; you already know the endpoint. For unknown or uncategorized ones, decrypt selectively: outbound, run data-leak prevention so sensitive content cannot reach an endpoint nobody has evaluated; inbound, scan what returns, because content from an unvetted source is where malware and poisoned instructions enter, and an agent that ingests it will act on it. That confines cost and breakage to the traffic that warrants scrutiny and concentrates inspection where your knowledge is weakest.
Everything so far concerns traffic leaving your environment. The east-west direction, agents calling other agents and tools, needs the same discipline applied to internal reach, where least privilege does the work. That is what checks lateral movement by a compromised agent.
An agent should reach only the internal endpoints its task requires. A customer-support agent has no business reaching a code repository, and a build agent has no business reaching a payments API. Scope each agent to what its job demands, express that once in its definition, and enforce it at the boundary rather than trusting the agent to behave. On a flat internal network the opposite holds by default: any agent reaches almost anything, so one hijacked agent inherits the whole environment's reach.
Treat these calls as trust-boundary crossings, not free movement: mutual authentication, inspection out and back, and segmentation so the internal endpoints an agent can reach are as deliberately chosen as the external ones. The return path matters as much as the request: a response from a compromised agent or tool is another way poisoned instructions arrive. The protocol layer is young too: the default MCP transport shipped at the end of 2024 with insufficient authentication, so do not assume these hops are safe[vi].
Finally, make the traffic answerable. Every outbound flow should be attributable to a specific agent, its owner, and the human it acted for, and queryable afterward. "Which external destinations did any agent reach this month, and which agent reached them" should be one question with one answer at the boundary, not a forensics exercise after something has gone wrong. Where you do inspect payloads, pair the flow record with what was sent.
Knowing an agent is an agent is necessary but inert on its own. That knowledge becomes an enforceable limit on the outbound path, the last point where a decision can be made that the agent cannot override. Corrupt the model, poison its inputs, talk it into a plan no designer imagined, and the data still has to leave through an exit you control, provided there is no other way out.
The agents are already calling out. The work is making sure something is deciding, on your behalf, which of those calls should ever leave the environment.
This article was published under HackerNoon's Business Blogging program.
[i] HackerNoon, The Impostor in Your Environment Is the AI Agent Holding a Valid Credential.
[ii] Legit Security, CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code.
[iii] Zenity Labs via PR Newswire, Zenity Labs Exposes Widespread “AgentFlayer” Vulnerabilities Allowing Silent Hijacking of Major Enterprise AI Agents Circumventing Human Oversight.
[iv] Cisco, Encrypted Client Hello (ECH) Defense Strategies: How Cisco Secure Firewall Tackles ECH.
[v] GitHub Advisory Database, Egress Policy Bypass via DNS over HTTPS (DoH) in Harden-Runner (Community Tier).
[vi] Vectara, MCP’s Rapid Journey: From Open Door to a Fortified Gateway
2026-09-28 23:15:38
Privacy programs have to keep up with constant updates:
For most programs, the challenge is keeping the records accurate with impactful changes. The problem becomes more obvious once a regulator, a customer, or a
That’s why, there’s more to research than feature lists when evaluating privacy platforms. Buyers today need to know:
The answers depend on how well the platform performs against eight criteria.
The point of a privacy platform isn’t to give your existing spreadsheets a new home but to move away from a disconnected setup. You need to evaluate how a platform keeps your privacy records, workflows, and evidence connected over time, as well as helps you comply with privacy regulations such as the
Under
What good looks like: The record updates as systems, vendors, and data flows change, so your team doesn’t have to wait for an annual review. It should also capture the different roles your organization takes across data processing activities, since you may act as a
Ask: How does the record stay current as our environment changes? Does it cover both controller and processor obligations? How quickly can we produce the record when an auditor, regulator, or customer asks for it?
How Vanta approaches it: Users get a
Under
What good looks like: The DPIA links directly to the relevant processing activity and RoPA, keeping the assessment and the activity it evaluates connected in the software.
Ask: Is the impact assessment linked to the record of processing, or maintained separately? What does the platform contribute beyond a template, and how much is still manual?
How Vanta approaches it: The impact assessments on Vanta carry risk predictions and tie directly to the processing activity in both the data inventory and RoPA. A
Your privacy program needs an accurate map of what personal data you hold and where it flows. Without it, you can’t demonstrate lawful processing, and every privacy workflow that relies on that information inherits the gaps.
What good looks like: The platform should build a more complete view of data flows from connected systems and minimize reliance on annual questionnaires. How much of the inventory is populated automatically is one of the strongest indicators of whether it will stay accurate over time, and
Ask: Is the inventory built via integrations, bulk import, or manual entry? What percentage is populated automatically today? Can processing activities connect to controls, risks, and vendor records?
Under the GDPR, individuals can request access to their personal data, and
What good looks like: Your privacy software supports native intake, deadline tracking and per-category fulfilment, with an audit trail. DSAR support varies between platforms and may be limited in broader privacy suites, so consider the level of functionality your program needs. If subject requests are your most urgent problem, evaluate this criterion first and on its own. A platform that’s strong across everything else may still fall short on DSARs, and finding that out after signing up can be expensive.
Ask: Is subject-request handling native and available today, or planned? How are deadlines tracked? What happens during a volume spike?
Running privacy separately from your security and compliance programs duplicates work. Teams end up evidencing the same controls in different tools for different audiences, and the records can drift apart due to infrequent updates. Connecting these programs lets teams reuse evidence and see privacy risk alongside the rest of the organization’s risk.
What good looks like: Privacy connects to the
Ask: Is privacy managed in the same system as security and compliance? Do privacy risks appear in the enterprise risk register, or in a privacy-only view?
How Vanta approaches it:
Here’s how
"Privacy can quickly become a massive manual overhead. Vanta integrates our core privacy workflows directly into our broader security ecosystem. Centralising these processes does more than just check a box; it strengthens our entire risk posture. Having that single source of truth gives us actual clarity on how we're performing."
If your organization heavily relies on consumer-facing data collection, a consent management platform (CMP) may be a baseline requirement alongside your privacy software.
What good looks like: Look for consent collection, preference management, cookie scanning, and categorization across your web properties. A privacy suite may offer lightweight consent capabilities, while a dedicated CMP typically provides deeper functionality. If you need enterprise-grade consent, evaluate it separately and compare it with dedicated solutions.
Ask: Is
The more jurisdictions your organization operates in, the more regulatory requirements your privacy software needs to keep track of. Organizations operating across the EU, the UK, and multiple US states may have to manage several privacy regimes at once, with more expected in the future. That’s the gap to watch: many privacy platforms can sound comprehensive while still skipping some of your actual obligations, leaving your team to manually track requirements across separate tools.
What good looks like: Prioritize native support for the regimes you're actually subject to, with jurisdictional variation handled rather than flattened into a generic framework. Verify coverage for the standards that apply to you. Coverage of GDPR,
Ask: Which frameworks are natively supported today? How are jurisdiction-specific variations handled? How fast is framework content updated when a law changes? Are users notified of such updates, and how soon?
How Vanta approaches it: Vanta natively supports privacy frameworks for
GDPR
What good looks like: The deadline is tracked from detection, with the notification workflow and its evidence trail kept with the incident for easy retrieval.
Ask: Does the platform support breach notification workflows? Does it track the GDPR’s 72-hour deadline from detection, and where does that evidence live?
Once you set up a vendor call, use these questions to pressure-test the platform:
Privacy or
No platform covers all eight criteria equally well, but choosing based on the breadth of the feature list may not be a reliable solution. DSARs and consent management in particular can vary significantly, and some organizations may need a privacy suite alongside a specialist tool. A good approach is to find the two or three features that matter most to your program and closely evaluate those before finalizing the software.
If GDPR is your primary focus, see Vanta’s
2026-09-28 22:16:53
I didn't join Shipaton because I had a big startup plan.
I saw an ad saying there was prize money for winning apps, and I thought: why not give it a try?
At that time, I was working on an idea called Book of Me, a journal app built to feel like a book. [link to my first article] I liked the idea. I thought the design could be different from other journal apps. But honestly, my thinking was simple:
"This is a cool idea. It should work."
After Shipaton, I don't think like that anymore. Now when I see an app, I ask different questions. What makes people want to use it? What makes someone pay for it? What does it have that other apps don't?
And probably the biggest one: what can I do differently with the resources I actually have?
That change in thinking is the biggest thing I got from Shipaton.
When I started Book of Me, I used AI a lot for design ideas. I could ask for a beautiful screen, get an image, and think: "Wow. This is exactly what I want."
It felt like I had already solved the design problem. Then I had to actually build it.
An AI image doesn't have to work. It doesn't care whether the user taps something, what the screen size is, whether Flutter can do it, or what happens after a button press. It just has to look good. Some of those designs looked amazing as images and were terrible ideas for a real app.
So I changed my process. Before, I asked: "AI, make something like this." Now I ask: "This is what I want to create. Help me make it."
I still use AI a lot. I just don't want AI deciding what my product should be.
Shipaton changed my social media feed. I followed Shipaton judges and other developers, and I started seeing apps that were doing well. People were talking about monetization, design, onboarding, paywalls, and user experience, things I wasn't thinking about before. It was like I'd been building inside a small bubble, and someone opened a window.
Sometimes that wasn't comfortable.
I saw an iOS app that everyone seemed to love, including the Shipaton judges. Its design and interactions were on another level compared with mine. I tried to create a similar 3D paper-curl effect in my own app, and I couldn't do it. I tried again. Still couldn't.
iOS has this kind of effect built in. In Flutter, as far as I could tell, I'd have to build it myself with custom painting, and I couldn't get it smooth enough.
I'm an Android developer working in Flutter with limited resources. Other developers had different tools, more experience, and sometimes paid AI tools I couldn't justify. For about ten days, I was stuck thinking maybe I just couldn't compete. That was one of the worst periods of the whole experience.
Eventually I realized something obvious. Why was I trying so hard to build exactly what another developer had already built?
Maybe the answer wasn't to keep trying forever. Maybe the better question was: "What can I make instead?"
That's when things started changing. Instead of the paper curl 3D, I built a page that moves over the other screens. Different animation, but something I could actually build and rather than delievering noting.
It happened again with sharing. I saw an envelope animation and wanted something like it, but I couldn't make it. So I made something different: the text appears on a card, and then a seal appears on it. Is it the same? No. But I stopped caring about making it the same. I started asking: "If I can't create that, what can I create in that direction that I can actually do?"
I'd already dropped a laggy 3D book animation earlier (I wrote about that in my first article). Now I could see the pattern: build for the resources you have, not the vision you imagined. And doing something different is better than doing nothing.
After I stopped comparing everything to other apps, I got more productive. Before Shipaton, I had no idea what an interaction was. Now I feel I have a real grip on how to make one that makes users feel good. My rule is simple: every interaction should match the app's theme and leave the user feeling calm.
None of this was in a master plan on day one. It came from experimenting, after I stopped asking "how do I make my app as good as theirs?" and started asking "what would be cool in my app?"
Shipaton is a competition, and at first I cared about winning. There was prize money, there were judges, and there were people building impressive things.
But after comparing myself with other developers for so long, I started thinking about giving up. I actually told people in the Discord that I didn't know what the point was anymore. They helped me a lot. They said they knew they might not win either, but they were still doing it, because everyone is bad at their first attempt.
That stayed with me. I stopped asking "can I win?" and started asking "can I deliver my best?"
I didn't expect to learn so much just from seeing other people build. On Discord, people gave feedback: a different font, something missing on a screen, an idea I'd never considered. On X, I found developers sharing what worked, what failed, and what they were building.
It even shaped my app's name. I originally wanted to call it Lifebook, but that name was already taken. Book of Me has three words, and apps usually avoid that. So I asked Klemmens, a Shipaton design judge, on X. He told me the three-word name had worked well for him with his app Art of Fauna, and he's now launching more apps in the same naming style. That helped me settle on Book of Me.
Rhys helped me in every question which i asked my revnenueCat and he even suggested me font package but i could not implement because that was Ios Package and my app was android.
Seeing the real market also matters. You can spend months building and think you're doing great because you've never looked at what everyone else is doing. Then you look and realize there's much more going on. For me, that wasn't discouraging forever. It became motivating.
Before, I mainly thought about features and design. Now I look at an app and wonder: what makes someone pay for this?
I got interested in paywalls and how successful apps present premium features, and I started paying attention to RevenueCat. I like the idea of a business that grows when the developers using it grow.
I don't want to pretend I became an expert in monetization. I didn't. But Shipaton made me realize that building an app isn't only about making something cool. At some point you have to ask why a real person would care about it, and, if you want income from it, why they'd pay for it.
At the time of writing, Book of Me is submitted for production review on Google Play. I submitted it on 22 September for production level. [If it's live: the link goes here.] Waiting on review near a deadline is stressful, and it taught me to plan store review time much earlier than I did.
Looking back, my biggest mistake was trying to follow every impressive design I saw. I'd see something cool, decide I needed it in my app, try to build it, get stuck, and feel my app wasn't good enough. That cycle wasted a lot of time.
If I started again, I'd first ask: why does this feel good? Maybe it's the movement, the surprise, or the way it fits the product. Then I'd take that idea and make my own version, not a copy.
If you're looking at another developer and thinking "there's no way I can reach their level," I understand. But you're comparing your current work with their best work, and that's not a fair comparison.
I'm not writing this because Shipaton turned me into a successful entrepreneur. It didn't. What it did was more useful to me. It showed me the real market. It showed me developers much better than me at things I wanted to learn. It made me uncomfortable, and it made me want to quit for ten days.
But it also changed me. I became more serious about design and more aware of monetization. I learned to work within my real resources, stopped copying everything I saw, and started using AI differently.
When I started, I thought: "This is a cool idea. It should work." Now I think: "What can my app do that other apps are missing?" That's a much harder question, and a much better one.
Shipaton didn't just change Book of Me. It changed how I look at building. If there's one thing I'd take from it: do what you can do best, follow your own vision, and nail it.
