Architecture arguments, engineering notes, and the things we got wrong on the way — written by the people building AgentOS.
Enterprise AI agents are becoming capable of much more than answering questions. They can update records, create tickets, retrieve business data and execute actions across enterprise systems. But as AI agents gain access to more tools, a critical security question emerges: how do you control what an AI agent can actually do, even when its instructions are ignored or manipulated?
Open your version control system and sort recent commits by author. Near the top, by volume, sits an account that is not a person: automation-bot. ci-service. platform-integration. Nobody remembers who created it. Its token hasn’t been rotated in a while. And after three years of absorbing whatever each new use case needed, it has more access than any engineer you employ.
There is a particular kind of demo that always lands well and almost never survives production. An agent proposes an action. A neat approval card appears. Someone clicks approve. The agent continues. Everyone in the room understands immediately that this is the right shape — the AI proposes, a human disposes — and the meeting ends on a high note.
Here’s an experiment worth running on your own architecture. Take any two agents in your estate with no business talking to each other. Now imagine one obtains the other’s network address — from a config file, a log line, an error message, or a document it was asked to summarize. What stops the call?
For most deployments, the honest answer is nothing, or something that wasn’t designed to. The agents share a network and a protocol; one has the address. The call goes through.
Identity for non-human workers, delegated authority that only ever narrows, and why a permission decision must never be read from a token Ask most teams what identity their AI agent uses, and you get one of three answers — all variations on the same shrug. An API key someone generated. A service account older than…
Why enterprise AI stalls at governance, not intelligence — and what the last four platform waves already taught us about fixing it There is a conversation happening in enterprises right now that follows an oddly consistent script. A team builds an AI pilot. It works. It works well enough that someone senior sees it and…
The arguments we would make in writing are easier to make on a running cluster. Bring your hardest governance question to an architect.
