What CISOs are saying in RSAC hallways that they'll never say on stage.
The second day at RSAC, I heard this conversation in every hallway. "I've got three teams piloting agents. I can't tell my CEO who owns them, what they can touch, or how to shut one down if something goes wrong."
I heard versions of that conversation all week. From enterprise CISOs. From heads of product. From people whose actual job is preventing the thing they just described. From compliance leads who already see the audit coming.
Here's what makes it worse. I'm the person who wrote the governance spec for this problem. And I've made every mistake they're describing. In my own systems. After publishing the framework.
That's what I want to talk about this week.
Key takeaways:
Four questions decide whether you're governing your AI agent or just watching it: Owner. Scope. Failure definition. Kill switch.
One AI agent's 2% error rate on customer-facing emails took six months to recover from after real customers called.
$300 vanished in one night when the Atti orchestrator in my OpenClaw lab spawned 47 copies of Scout in a runaway loop.
AI agents lose memory under long sessions. A six-hour drafting session can compress to a useless summary, and the commitments inside it can vanish.
The free local model that fails silently costs more than the paid model that works. Match capability to task, not cost to convenience.
What pattern keeps showing up in failed AI agent deployments?
The demo works. The model is capable. The deployment collapses because the human layer around it was never built. A consultant I worked with last year had a client who did everything right on paper. Capable model. Impressive demos. A strong use case. A real budget. Then they went straight to full autonomy. The agent had a 2% error rate on customer-facing emails. Sounds small. Until real customers called.
Production collapsed. Six months rebuilding internal trust.
The failure wasn't technical. The model worked exactly as designed. Nobody had defined what the agent was allowed to do wrong before someone had to answer for it.
The CISOs who navigated RSAC well weren't the ones with the most sophisticated controls. They were the ones who changed one thing: the language they used with leadership. They stopped leading with risk. They started leading with what governance makes possible.
"With these controls in place, we can deploy this agent in two weeks" lands completely differently than "we need to complete our security review." Same outcome. Completely different relationship with the business.
The roll cage doesn't slow the car down. It makes sure the driver walks away when something goes wrong at speed. Governance isn't what stops AI from delivering value. The absence of governance is what stops it, when the first visible mistake forces leadership to pull the plug entirely.
What 10-minute question reveals your AI agent governance gap?
One conversation in 10 minutes can be more revealing than any audit. Ask your IT lead, your engineering lead, and your business unit heads the same question, separately, before they've compared notes:
"What AI agents or automations are running in our environment right now, and what systems do they have access to?"
You'll get different answers.
That governance gap is something you can't close until you can see it.
What four questions should you answer before deploying an AI agent?
Four questions, answered in writing, before any agent touches a production system. It's not a security review. It's a governance conversation that takes thirty minutes and happens before anyone writes a line of code.
Owner. One named human accountable for this agent's behavior. Not a team. Not a department. One person whose name is on it and who gets the call at 2 a.m. when something goes wrong. If you can't name that person, the agent doesn't deploy.
Scope. A written list of what this agent can access, initiate, or change. If it's not on the list, the agent doesn't do it. Almost every team makes this mistake: they define scope by system, not by action. "This agent has access to the CRM" is not a scope definition. "This agent can read contact records and log call notes, and cannot modify deal values, delete records, or access billing information" is. The difference counts enormously when you're explaining to a regulator what the agent was authorized to do.
Failure definition. A specific written answer to: what does this agent do wrong that triggers human review? Not a generic error threshold. A named behavior. "If the agent sends an external communication that wasn't explicitly requested." "If the agent modifies a record outside its defined scope." This is the question almost nobody asks before deployment. It's also the one that determines whether you're governing the agent or watching it.
Kill switch. Who can shut it down, and how fast? If the answer involves physically running to a computer, you don't have a kill switch. You're hoping you can shut it down if needed. Hope isn't enough. You need to be able to fire your AI agents.
Where did the Agentic Trust Framework author get burned?
I'm the author of the Agentic Trust Framework. I advise CISOs on AI agent security. I co-wrote a book on this with John Kindervag. I still got burned. Multiple times. Many times this week. Four specific failures inside my OpenClaw home lab taught me more than any framework ever could.
Quick context. I run a team of AI agents on a dedicated computer in my home lab. Think of it like a small company where every employee is an AI. Atti is the manager. It decides what needs to happen and delegates. Forge writes code. Scout does research. Quill handles writing. Each one has its own workspace, its own access limits, and can only touch the systems I've specifically approved. That's the Agentic Trust Framework in practice.
And now for the fun part. Four failures that taught me more than any framework ever could.
What happened the night Atti spawned 47 copies of Scout?
Atti checks in every 30 minutes, like a manager doing rounds. "Anything need doing?" Beautiful in theory. Then a vague instruction caused Atti to hand off a research task to Scout. Scout came back with a result. Atti looked at the result and decided it needed more research. So it created another copy of Scout. That copy produced another result. Atti created another copy.
By 6 a.m., I had 47 copies of Scout running at the same time, each one racking up charges against my AI provider account. No alarms went off. No spending limits kicked in. $300 gone overnight.
The agents were doing exactly what they were told to do. That's the worst kind of failure. Only I was to blame.
My own framework had the answer. It says you need to watch for abnormal behavior patterns: spending spikes, agents multiplying, tasks repeating in loops, and recursive delegation. I had the framework and have implemented it dozens of times for clients. I just hadn't wired it up to my own system yet.
What I changed: agents can no longer create copies of themselves. Only Atti can assign work, and only one level deep. Every 30-minute check-in has a spending cap. If total daily costs hit a threshold before 6 p.m., everything pauses and I get a notification on my phone.
None of this required buying anything new. It just required governance discipline. Rules written down and enforced before the next thing went wrong.
Why did locking down Forge break the work?
Forge, my coding agent, runs in a locked-down environment. Think of it like a room with no windows and no phone. It can only use tools I've specifically put in the room. It can't reach the internet. It can't touch files outside its workspace. Perfect from a security standpoint.
Then I gave Forge its first real coding task. It needed to download a standard software package to do the work. Blocked. It tried a workaround. Blocked. It tried a third approach. Still blocked.
I had a coding agent that couldn't do its job without me manually carrying files into its workspace like passing notes under a door.
Here's what I got wrong. I built the security controls first and assumed I'd figure out the work part later. That's backwards. Clearly stated in the framework. I spun this up in a hurry. A governance system that prevents your AI from doing its job doesn't improve security. It creates pressure to work around the controls. "Just give it full access this one time" becomes permanent. That defeats the whole point.
This is exactly how shadow IT was born in the 1990s. IT locked everything down. Employees found workarounds. Security got worse, not better. The same thing is happening right now with AI agents.
Everyone from the marketing director to the receptionist is building agents, whether you let them or not. So you can't clamp down on security. It's on us to make the secure path the easy path. The golden path principle: the secure way to work must also be the easy way to work. If following the rules is harder than breaking them, you've already lost.
What I changed: instead of blocking all outside access, I approved a short list of specific, trusted sources Forge can reach. Nothing else. And I built an approval process. When Forge needs something new, it requests access, I approve it once, and it stays on the permanent list. After two weeks, the approved list reflected how Forge actually works, not my guesses about how it would work.
How did six hours of work disappear overnight?
Atti and I worked for six hours on a strategic initiative. We developed a complete client briefing, drafted follow-up emails for three contacts from a high-value dinner meeting, started a critical technical response for a partner, and outlined next week's deliverables. Most productive session I'd had in months.
Woke up the next morning and sent Atti a message.
Atti had no idea any of it had happened.
Here's why. AI agents can only hold so much in their working memory at once. When a conversation gets long enough, the system compresses older parts to make room. My six hours of detailed work got squeezed into a vague summary that was useless for picking up where we left off. I spent two hours the next morning re-explaining everything we'd already covered.
This is the same failure mode researchers like Summer Yue have flagged. Compression doesn't just eat safety instructions. It eats the record of what your agent decided, drafted, and committed to. An agent running entirely on working memory is an agent with no paper trail. No continuity, no accountability.
Now imagine this at your company. An AI agent is handling a vendor negotiation in the background. The conversation gets long. The system compresses. A conditional clause the agent agreed to gets lost in the summary. Nobody knows. Your company is now operating on a commitment it can't verify.
That's not a hypothetical. That's a Monday morning at any given company.
What I changed: the rule is now "write it down the moment it happens." Any time a decision is made, an action is completed, or a status changes, Atti saves it to a permanent file immediately. Not at the end of the session. Not when memory gets full. Now. Working memory is a scratchpad. The file is the record of truth.
Why did the local model fail silently on hard tasks?
Running AI models on your own hardware instead of paying per use sounds great. No ongoing costs. Full privacy. Your data never leaves the building. Your finance team likes the line item.
I set this up for Forge. Simple coding tasks worked fine. Then I gave it something harder: reorganize a complex set of interconnected files, fix a timing issue, and update all the related documentation.
Forge started confidently. The code it produced looked right. Professional. Well-structured.
But it didn't work. It pulled the wrong file references. It introduced new problems while fixing old ones. The documentation didn't match what was actually built. I corrected it. It tried again. Different mistakes each time. After three rounds, no progress.
The local model was good enough to produce work that looked correct to someone glancing at it, but couldn't hold all the moving pieces of a complex project in its head at once. The worse problem: on harder tasks, it would sometimes just stop in the middle of the work without any error message. It looked finished. It wasn't.
The failure was in matching capability to task. I didn't have a capability profile for my agents. I had a cost profile: "the local model is free, so use it." That's not governance. That's wishful thinking.
The free model that fails silently costs more than the paid model that works. That math applies at every scale. The silent failure is the dangerous one, because someone downstream is going to trust that output.
What I changed: simple, well-defined tasks go to the local model. Complex work that touches multiple systems goes to the more capable model, even though it costs more. I added a basic check: if an agent's output is significantly shorter or simpler than what the task required, flag it for review instead of treating it as done.
What do all four lab failures have in common?
The agents were doing exactly what they were told. In every case. The technology worked. The governance didn't. I wrote the framework. I still got burned. Not because the framework was wrong, but because I hadn't finished applying it to my own system.
If the person who built the governance model can make these mistakes, what's happening inside organizations that don't have a governance model at all?
What separates teams that govern AI agents from teams that don't?
It's not budget or tooling. It's not technical sophistication. Someone asked the four questions before the first agent touched production. Owner. Scope. Failure definition. Kill switch. Thirty minutes. Written down. That's it.
I published these failures because the gap between "I advise on this" and "I built this and got burned" is the gap most of the industry is hiding behind right now. Vendor whitepapers don't include the part where it went wrong. Conference talks don't include the $300 overnight surprise. The frameworks, including mine, only work when someone does the unglamorous work of wiring them into real systems.
Frequently asked questions
What's the difference between a security review and a governance conversation?
A security review evaluates an agent against a checklist after someone has already designed it. A governance conversation defines who is accountable, what the agent can do, what counts as a failure, and how to stop it, before anyone writes a line of code. Both matter. The governance conversation is the one teams skip.
How is "scope by action" different from "scope by system"?
"Access to the CRM" tells you nothing about what the agent will actually do. Scope by action lists the specific verbs: read contact records, log call notes, never modify deal values, never delete records. A regulator or an auditor needs the second version, not the first.
What's a real kill switch versus a fake one?
A real kill switch can be triggered remotely, by more than one person, in seconds, without depending on a specific computer or network connection. If your kill switch requires someone to physically run to a workstation, log in, and type a command, you don't have a kill switch. You have a hope.
How do you stop an agent from quietly losing decisions in working memory?
Write everything down the moment it happens. Decisions, actions, status changes go to a permanent file the agent and the human can both read. Working memory is a scratchpad. The file is the record of truth.
Where do I start if my company has zero AI agent governance today?
Run the 10-minute question with three different leaders. Get their separate answers about which agents are running and what those agents can touch. The gap between those answers is your starting point.
The bottom line
If your security team can't tell your CEO who owns each AI agent, what it can touch, and how to shut it down, your company isn't governing AI. Your AI agents are governing your company. The fix isn't more tools. It's thirty minutes of conversation, four written answers, and the discipline to stop a deployment that can't pass them.
What AI agents are running in your environment that your security team doesn't know about?
Want to see where your organization stands? The free Agentic Trust Framework assessment at verifiedagents.ai takes ten minutes. For a deeper read, check out Agentic AI + Zero Trust: A Guide for Business Leaders and the Agentic Trust Framework.