Eventually, every agent will drift from what you wanted it to do. It doesn't matter if you tell an agent to draft emails. With enough runs or after enough repetition, a small per-run error becomes a near-certainty. If it has send access, ‘draft only’ doesn't really matter. Every agent builder has this problem. We catch this by running a model at runtime that compares the stated intent against the action the agent is about to take. And, of course, logging the entire agent history. If you're not doing this, you can't just hope a better prompt + an LLM judge will fix everything.

You are overthinking agent improvement. We literally have an agent that connects to our session history and tells us what we are doing over and over that could be automated. If you want a guide to tell Claude / Codex: 1. Agent queries your session data (last week or month) 2. Identifies repetitive or structured tasks appearing across sessions 3. Returns: "You're doing X manually every week, here's the agent spec to automate it" 4. Output is an agent brief, not just a suggestion Then you feed that into Codex to make a new agent that does 90% of the thing you were already doing. Simple as.

"We need to detect prompt injection" is 100% the wrong framing for actually detecting an attack. It's a game of cat-and-mouse if you're looking for adversarial content directly in prompts. Better detection method is intent drift: does the agent's observed behavior match what users understood they were authorizing? We run a small session-level model that compares original intent against trajectory of the agent. It's built to flag hidden instructions, goal substitution, and post-injection behavior, regardless of whether an "injection" occurred. Track what the agent was supposed to do, then flag when it deviates.

Every enterprise employee basically has an unsecured extension of themselves via their agents. Full disk and accessibility access are a gnarly combination of: - all or nothing - granted per app, not per task - permanent until someone revokes them So now, you fix one bug once, and every task after that has whatever permissions you granted. Importantly, the problem isn't about agents acting as you. An agent should inherit the caller's identity, and that's the setup we use at Runlayer. The problem is an agent inheriting the user's entire reach, again and again, for any action. What’s missing is access scoped to the task: what the agent can touch, for how long, checked at the moment it acts. Until the OS gives us that, start by finding out which agents already hold these grants. h/t @sriramk

Within 18-24 months, every enterprise will have an AI platform team. 15 years ago there was no cloud infra team. Now every company has one. 10 years ago there was no data platform team. Then all of a sudden you have Databricks and Snowflake, and there's a data platform team. If you asked 50 Fortune 500s today "Where does this all live?" They'd say it lives somewhere between security, IT, or we have no idea. There's too much infrastructure here that has to be controlled, coordinated, aligned. And over the next 18 to 24 months, you're going to see a new function. That's the AI platform team.

Adding AI to your marketing doesn't make you an AI company

Governance can be a dirty word. If it starts with "What do we block?" it's basically fear-based framing of AI adoption. I try to default to enablement: just having the same controls, built in-path, so people can get that ROI and the 10x opportunity that everyone wants. Make the approved path the easiest possible path.

Accenture should hire some consultants to optimize their AI usage. xitter.cf/josephfcox/status/2110…

Putting a WAF in front of your agents is a really bad idea if it's your only idea for security. It sounds like it should cover you, but what it doesn't cover is too large. We make about 10M tool calls a week, and a WAF in front of our prompts wouldn’t inspect any of them. What it doesn't cover: - Agent-to-LLM exchanges happening inside the reasoning loop - MCP tool calls (inputs and outputs) - GraphQL traffic - Multi-tool chaining behavior (what the agent does with tool results) - Fleet-level behavior: one agent writing to a shared resource that another agent reads - Agent-to-agent attacks You basically get to check the prompt, and there's a gigantic black box of agent activity after that. It should be one part of your larger agent security strategy, sure. Just don't rely on it for catching everything. The next step is to watch tool calls first, then enforce inline on the ones that can do real damage.

Overheard a CISO describe how he gives agents a named human manager, unique least-privilege credentials, and calls them digital workers. Production agents need 2 sign-offs: the agent’s manager and the data owner. He even reassigns the agents if a manager leaves the company. It might sound silly, but this is the right call. He's mirroring how everyone treats employees. He already has a mature answer to who is accountable for a worker, what happens when their manager departs, who signs off on giving them access to payroll data. He simply didn't invent a second, worse system for agents.

If you're not tuned in to enterprise AI adoption, let me tell you that no one knows what they're doing. It's a gigantic power struggle between governance, security, AI enablement, IT, data science, all between one set of agents. All while the board says "We need to be AI native" without a clue what that actually means. If you're at a small startup that's using agents and skills and domain-specific harnesses, be very grateful.

Observability, intent and runtime controls are going to become one of the most important layers in AI.

Spend is easy. ROI is hard. That’s why we solved it

Imagine a future of 1000s of personal agents. The amount of events and data we’re about to see is unprecedented and this is just the beginning

"We'll just have an LLM make the call" is a horrible policy for policing your agents IMO Your costs scale with usage and you just create another slow, unreliable prompt injection layer We learned this the hard way early on when building out infrastructure for @Runlayer, and the fix we landed on is unsexy, but effective You train a small, purpose-built model for one narrow question ("Does this action still serve the goal the agent was given at t=0?") and run it as fixed infrastructure. This small model has one job, and it runs cheaply. The cost just scales when you add more machines to run the small model. We always want to solve classification problems with classification, not reasoning

The amount of times folks have dunked on MCP only to see the entire ecosystem embrace it