Microsoft Cited My AI Security Framework. Here's What Their Tool Still Can't Do.
AI agents are running your business. Here's how to keep them from running it into the ground.
Thirty days.
That’s how long it took after I published a governance standard for AI agents before two separate organizations, one inside Microsoft and one out of Berlin, had already built their own tools against it.
I didn’t ask them to. I didn’t know they were doing it. They just found the framework, decided it was the right foundation, and built.
That’s what validation looks like in the real world.
A Safety Net Is Not a Safety Plan
Last week, Microsoft released a free toolkit that puts guardrails on AI agents. Before your AI agent does anything, the toolkit checks: is this allowed? If not, it blocks it. It works with 12 of the most popular AI development tools right now, including LangChain, AutoGen, and OpenAI’s platform.
In their documentation, they listed the Agentic Trust Framework as a reference. That’s the governance standard I built, published by the Cloud Security Alliance in February. Microsoft looked at the entire AI agent security landscape and put my framework alongside the biggest names in the field.
And here’s what I respect most about Microsoft: they’re honest about what their toolkit can’t do. Right there in the documentation. The tool watches what agents do inside the software. It doesn’t control what happens at the computer level underneath. And it doesn’t keep agents from talking to each other in ways they shouldn’t.
That’s rare. Most security vendors sell you a full solution and deliver half of one.
But it means someone still has to answer the bigger questions. Who approved this agent to run in the first place? What company data can it see? What happens when it starts behaving differently than it did during testing? Who do you call at 2 AM when something goes wrong?
Those aren’t questions for your developers. They’re questions for whoever is running the business. And right now, most leaders don’t have answers.
30 Days. Two Organizations. That’s Faster Than NIST Moves in Years.
Here’s why the timeline matters.
When I published the Agentic Trust Framework in February, it was a blog post on the Cloud Security Alliance website. No press release. No marketing. Just a framework with a GitHub page.
Thirty days later, two independent organizations had already built tools that reference it: an engineer inside Microsoft, and a company in Berlin building AI governance tools. Neither of them contacted me first. They found it, used it, and then reached out after.
For context: the frameworks published by the National Institute of Standards and Technology, the U.S. government body that sets the official security standards, typically take years to see this kind of independent adoption. Years. Not weeks.
In the world of standards and governance, that kind of early traction doesn’t happen by accident. It happens when a real problem exists, people are actively looking for answers, and they find something that actually fits.
AI agent security is that problem right now.
What Microsoft’s Toolkit Leaves Unanswered
I mapped the Microsoft toolkit against the Agentic Trust Framework to find exactly where the toolkit stops and where your leadership team has to start.
The toolkit gives every AI agent a unique digital ID. That’s real progress. But it doesn’t answer: who hired this agent? Is there an approval process before an agent gets access to live customer data? Can you trace every action back to the person who authorized it?
An ID card tells you who the agent is. It doesn’t tell you whether anyone should have let it in the building.
The toolkit also lets you set limits on what each agent can do. Agent A can read files. Agent B can search the web. Agent C can only write. That’s the right approach. But those limits only apply inside the software layer. If the computer running the agent has broad access to your network, the toolkit can’t stop the agent from reaching things it shouldn’t.
Image: Per-agent permissions screenshot — Forge/Scout/Quill breakdown
The toolkit checks individual agent actions as they happen. But it doesn’t watch how an agent performs over time. It won’t notice that an agent that was accurate last week has gotten worse this week. It won’t catch that someone changed the agent’s instructions and the error rate tripled three days later. That kind of monitoring is a different job, and nobody’s fully built it yet.
The pattern across all of this: Microsoft solved the builder’s problem. Nobody’s solved the leader’s problem. The toolkit is the lock on the door. The Agentic Trust Framework is the policy that says who gets a key.
I Broke My Own Agent. Here’s Exactly What Happened.
I’ve been running a secure AI agent system on a dedicated computer in my home lab. The main agent’s name is Atti. I built the whole setup to test every principle I’ve written about. Build it, break it, document what goes wrong.
What went wrong first was me. And honestly, it’s almost embarrassing.
I set up the full architecture. Atti runs in a completely closed environment: no internet access, no ability to write files outside its own workspace. A separate agent handles anything that needs to touch the outside world. Clean separation. Every action logged.
And then I skipped a critical two-line setting because I was too excited to get started.
I forgot to turn on the memory backup.
AI agents have a working memory, just like a person in a meeting. When that memory fills up, the system has to clear it. There’s a feature that saves the important context before that happens. I knew it existed. I had written about it. I skipped it anyway.
The memory filled up. The system cleared it. Atti forgot everything. The project we were working on. The security decisions we had made together. The reasoning behind the whole setup. Gone.
So yeah. I’m the security consultant who built the framework and then forgot a two-line setting because he was excited about the tool. If that doesn’t tell you something about where AI agent deployment actually is right now, nothing will.
What You Can Do This Week
You don’t need a security team to start driving change.
Ask your technical team: “Are any of our AI agents using more than half of their working memory capacity on a regular basis?” If nobody knows, that’s your first gap.
Download Microsoft’s toolkit from GitHub (microsoft/agent-governance-toolkit) and read the first page. Even if you don’t write code, it explains clearly what the tool covers and what it doesn’t. Send it to your security lead.
Pick one AI agent your team uses today. Ask: “Who approved this agent to access our data? Is that written down anywhere?” A shrug is your answer.
Ask whether your agents have a kill switch that someone has actually tested in the last 30 days. Not “we have one.” Tested.
Ask IT: “What software is installed on the computers running our AI agents? Does any of it give agents the ability to install more software on their own?”
The Agentic Trust Framework gives you the governance layer that sits above any developer toolkit. The full specification is at the ATF GitHub repo. My book “Agentic AI + Zero Trust” walks through every question you should be asking, in the order you should ask them.
What I Fixed (Substack Lab Notes)
This is the part LinkedIn doesn’t get. Real configuration decisions from a real build.
Here’s what I changed and why it matters for anyone running AI agents.
I set the working memory limit to 200,000 tokens, roughly 150,000 words. AI companies advertise much larger limits. But research shows that models start performing worse at about 50% capacity and fall off sharply around 65%. I’m not testing how far Atti can go. I’m keeping it well inside the range where it actually performs reliably.
I turned on safeguard mode for memory management. When memory gets too full, the system now saves important context first before clearing anything. And I set the backup to trigger at 40% capacity. At that point, the agent saves everything it has learned to permanent storage. If the memory gets cleared later, the important context survives.
Image: Forge and Scout build status
This is a gap the Microsoft toolkit doesn’t touch. An agent can pass every safety check and still be operating at half capacity because its memory is overloaded. The toolkit watches what the agent is doing. It doesn’t watch whether the agent still remembers why it’s doing it.
Lab Notes: What I Stripped Out of the System
The default software setup I was working with was a bloated mess. A full Go programming compiler. A full Rust compiler. A package manager called Homebrew that can install basically any software at runtime.
Image: What Forge does NOT need
Homebrew alone is a real problem. If an agent can install new software on the fly, the limits you set are just suggestions. The agent can go get whatever it needs to work around them.
What my coding agent actually needs: version control, JavaScript tools, Python, a couple of standard utilities. That’s it. Every tool justified. Nothing extra. Clean, and something I can explain to anyone who asks.
That’s what ATF governance looks like when you apply it to a real decision. Not a policy document. An actual choice about what goes in a container, made against real principles.
SUBSTACK EXCLUSIVE: Zero Trust Gap Analysis
The Microsoft toolkit assumes your agents are operating in a defined trust boundary. Zero Trust was built for humans and devices. It assumes the thing you’re verifying has a relatively stable identity and behavior profile.
AI agents break this assumption in three ways:
Memory drift. An agent operating at 80% memory capacity is not the same agent it was at 20%. Its behavior changes. Zero Trust has no mechanism for detecting behavioral drift in a stateful reasoning system.
Emergent permissions. Traditional Zero Trust controls what a system CAN access. It doesn’t govern what a system SHOULD access based on current task context. An agent approved to access customer records for one task will use that access across all tasks. Least privilege requires task-level scoping, not role-level scoping.
Inter-agent trust. When agents talk to other agents, Zero Trust’s verify-explicitly principle has no clear implementation. Which agent’s identity governs the interaction? The calling agent or the receiving agent? Right now, most deployments inherit the highest privilege in the chain.
The ATF addresses all three. The Microsoft toolkit addresses none of them. That’s not a criticism of Microsoft. It’s a definition of scope.
So here’s what I keep coming back to: if I, the person who built the framework, forgot a two-line config because I got excited about a new tool, what is your team skipping right now?
Until next week, Josh