In mid-March 2026, an engineer at Meta trusted an AI agent inside an internal developer forum. The agent analyzed a technical question and gave incorrect advice about access settings. The engineer acted on that advice. Within minutes, access settings changed. Restricted data was exposed to unauthorized colleagues for two full hours. Meta logged it as a Sev-1 incident. War rooms were spun up, access was revoked, and the blast radius was assessed.

No malicious outsider. No zero-day exploit. No compromised credentials. Just an AI agent acting as a confused deputy. It provided authoritative but wrong guidance, and nothing stood between its output and a live system.

This was not a one-off. It was not a bug to be patched. It was a sign of a fundamental shift in how systems fail.

59% of security leaders now report AI-related security incidents within their organizations, and 97% expect a major AI-driven incident this year. AI-related vulnerabilities and CVEs grew 34.6% year-over-year between 2024 and 2025.

The uncomfortable part: most teams are deploying agents into high-permission environments faster than they can assess what those agents can actually do. We are in the middle of an unprecedented land grab for AI productivity. Engineering leaders are pushing agents into production to automate ticket routing, query databases, generate reports, and manage infrastructure. Security teams are reviewing the prompts, but they aren't reviewing the permissions.

Your firewall wasn't built for this. Your SOC playbooks weren't written for it. Your identity and access management systems were designed for human users and predictable software. They were not designed for AI that reads its own instructions from the internet. And your agents don't care about your security posturing.

Traditional software does what you program it to do. A batch job runs at midnight. A form validates an input. A cron job rotates logs. The behavior is predictable, bounded, and testable.

AI agents are different in three specific ways that matter to security:

First, they interpret instructions from their environment. This means a hidden instruction inside a document, a webpage, or a Slack message can redirect them mid-task. We call this prompt injection, and it is not a theoretical vulnerability. It is an architectural reality of how LLMs work.

Second, they take actions using privileged credentials. We give agents API keys, database passwords, and file system access so they can actually be useful. But an agent with write access to a production database has the exact same power as a senior engineer with that access. The difference is the agent works at machine speed.

Third, they operate without per-action human review. If a human had to click "Approve" every time an agent took a step, we would defeat the entire purpose of automation. So we let them run.

Each of those three things is also what makes them useful. Each is also a massive, expanding security gap.

The old answer of adding safety instructions to the prompt does not hold up. Benchmark testing found that prompt-based safety has a 26.67% policy violation rate. More than 1 in 4 attempts to get an agent to break its own rules succeeded. With nothing more than clever phrasing. A hidden instruction in a support ticket or a poisoned document can bypass prompt safety nearly a third of the time.

You are asking a guessing system to make strict decisions. Sometimes it gets it right. Sometimes it gets lucky. At a large company scale, "sometimes" is a ticking clock.

On March 18, 2026, Microsoft released v3.1.0 of the Agent Governance Toolkit. It is an open-source framework that sits between your AI agent and the actions it actually takes. Not a prompt guardrail. Not content moderation. Not a word filter. A policy layer.

The architecture is simple to understand:

Every tool call, every file access, every API request gets evaluated against a written policy before it executes. Strict, not based on chance.

Result: 0.00% policy violation rate in the same benchmark tests where prompt safety failed at 26.67%.

And the performance overhead? Less than 0.1 milliseconds per action. Roughly 10,000× faster than a single LLM API call. Why does this matter? Because agents loop. An agent might take 30 actions to complete a task. If your governance layer adds 2 seconds of latency per action, the user experience is destroyed, and engineers will simply bypass it. At sub-millisecond overhead, the governance layer adds no meaningful latency, which means engineers actually keep it turned on.

Here is the simplest version. It is a policy that blocks two dangerous tools, nothing else:

Notice what isn't here. There is no complex prompt engineering trying to convince the agent not to delete the file. It simply lacks the capability. The rule is not a suggestion. It is enforced at the action layer, outside the AI's thought process. The agent cannot reason its way around it, because the execution engine simply will not run the call.

If your team works in TypeScript:

Same idea. Different stack. The toolkit ships with SDKs in Python, TypeScript, .NET, Rust, and Go. They all implement the same core governance model.

For more complex logic, you aren't limited to code. The policy engine supports plain YAML definitions, and integrates natively with OPA/Rego and Cedar for teams that already use policy-as-code in their infrastructure.

The toolkit is not one thing. It is four layers that address four distinct failure modes that are already showing up in production incidents.

The Policy Engine is the core. You write rules in plain YAML, or use OPA/Rego and Cedar for more complex logic. Every agent action runs through the engine before it executes. Sub-millisecond. Strict. While the Meta incident involved a human acting on bad AI advice, the more pressing danger today is autonomous execution. If an agent is granted direct permission to change access settings (which is where AI is heading), AGT ensures that action is evaluated against a policy and blocked before the change lands. No war room. No Sev-1. No incident report.

Zero-Trust Identity gives every agent a signed credential using Ed25519 keys plus quantum-safe ML-DSA-65 signatures. Trust is scored on a 0 to 1000 scale. Agents communicate through encrypted channels with trust gates. No agent can impersonate another. This matters for multi-agent systems, which are increasingly common in enterprise deployments. A rogue sub-agent cannot inherit the trust of a parent agent. If a summarization agent suddenly tries to authenticate as a database admin agent, the trust gate drops the connection immediately.

Execution Sandboxing puts every agent in one of four privilege rings (Ring 0 to Ring 3). A summarization agent cannot suddenly start executing shell commands. A data-reading agent cannot write to production tables. The rings are enforced at runtime. And there is a kill switch. If an agent goes off-script at runtime, you can terminate it immediately without taking down the surrounding system or corrupting shared state.

Agent SRE applies the same reliability engineering your infrastructure team already uses for microservices (like SLOs, error budgets, and circuit breakers) to agents. When something goes wrong, you have a full audit trail and a flight recorder. You can replay exactly what the agent did, in what order, with what credentials, against what data, and see the exact inputs and outputs at each step. This turns a 6-hour forensic investigation into a 10-minute replay.

In 2025, OWASP published the Agentic Top 10. It is a formal list of the ten most critical security risks specific to AI agents. It covers things like goal hijacking, excessive capabilities, privilege abuse, unsafe inter-agent communication, and rogue agents.

Before this toolkit, covering all 10 meant stitching together different tools from different vendors with no common policy model. It meant custom middleware, custom authentication wrappers, and a lot of praying. The Agent Governance Toolkit covers all 10/10, verified against 9,500+ tests.

For compliance teams working toward EU AI Act, NIST AI RMF, or SOC 2 alignment, this table is your starting point for a conversation with your legal team, not the end of it. But having a documented, tested governance layer makes that conversation significantly easier. It shifts the discussion from "How are we theoretically ensuring safety?" to "Here is the exact policy file, the enforcement mechanism, and the audit log."

The toolkit provides application-level governance, not OS kernel-level isolation. The policy engine and your agents run in the same process. That is the same trust boundary as every Python agent framework in existence today.

Because they share a process, a deeply compromised agent environment could theoretically bypass in-process guardrails. Application-level governance is not a silver bullet against a fully compromised host.

The production recommendation from the team: run each agent in a separate container for OS-level isolation. The governance layer handles what happens inside the application (the agent trying to do something it shouldn't). The container boundary handles what happens outside it (an exploited process trying to escape). Layered defense is the same principle you already apply everywhere else in your stack. Do not rely on a single layer.

Install takes about 90 seconds:

That last command, agt verify --strict, is worth integrating into your CI pipeline early. It runs the full OWASP Agentic Top 10 check against your setup and fails the build if your governance posture is below the threshold. This prevents ungoverned agents from sneaking through in late-night pull requests. Your security team will thank you. Your future self during an audit will thank you more.

The toolkit works with every major framework your engineers are probably already using: LangChain, CrewAI, AutoGen, OpenAI Agents SDK, Google ADK, Semantic Kernel, LlamaIndex, Dify, and Azure AI Foundry. It offers native middleware or adapters for each. You don't have to rewrite your agent logic. You just have to wrap it.

Engineers building agents: If your agent has access to file systems, databases, email, Slack, or any internal API, it needs a policy layer before it goes to production. It does not matter if it's an internal tool. It does not matter if it "only answers questions." Providing incorrect but authoritative answers to human operators is exactly how the Meta incident started. The 90-second install above is the floor. The YAML policy file is the ceiling. You own how restrictive or permissive it is.

Security and infrastructure leads: The Shadow AI Discovery module finds unregistered agents running across your processes, configs, and repos. Before you can govern agents, you need an inventory of what's actually running. You cannot protect what you do not know exists. Start there.

Compliance and legal teams: 68% of organizations currently lack any formal AI agent governance. Regulators are not waiting. The EU AI Act is live. NIST AI RMF adoption is accelerating. This toolkit maps directly to both frameworks with documentation your auditors can review. That is rare and valuable. It turns a subjective compliance argument into an objective technical artifact.

The Meta incident was contained in two hours. That is actually a good outcome by 2026 standards. Most agent security failures are not caught that quickly. Many are not caught until after the damage is done. This could be a deleted record, a leaked credential, or a customer database queried by an agent that was only supposed to check the weather.

The AI agent problem in enterprise is not primarily an AI problem. It is a governance problem. You would not give a new hire admin access to every system in your company on day one with no oversight and no written policies. You would not give them root access to production and say, "Just read the company values document and do your best." An AI agent without a policy layer is exactly that. It is an autonomous entity with root access, guided by an unpredictable instruction set, operating at machine speed, with no adult supervision.

The tooling now exists to close this gap. It is open-source, MIT-licensed, and 90 seconds from your first governed action.

The harder work of aligning security, compliance, engineering, and leadership on what the policies should actually say is still yours to do. The political battles over which teams get to deploy which agents with which permissions will be fierce. But at least now you have something concrete to build on. At least now, the next time an engineer asks an AI agent for advice on changing access settings, there will be a policy layer standing between the agent's autonomous capabilities and a live production system.

Resources & Further Reading

Thanks for reading.

— Rakesh's Newsletter