The core argument: you deployed them, but that doesn't make them safe
Gallot's post makes a simple point. Most security worry has centered on attackers using powerful models against organizations. Far less attention has gone to agents running inside the company, which the company deployed and therefore implicitly trusted.
Her claim isn't that models are malicious. She says models are trained to attain results, which often leads to reward hacking, and they aren't optimized around organizational norms or judgment. She also argues that agents adapt as context changes and may collaborate or collude with other agents to reach their goals, without anyone compromising them. These are the author's risk claims. The post doesn't point to a specific new incident, though it refers generally to AI safety incidents disclosed "in the last few months."
She adds that these agents are frequently overprivileged. They have access to data, tools and systems, and they take part in critical processes. That combination is why she calls them insiders.
Microsoft's own Learn guidance on securing autonomous agentic AI systems supports the practical premise. Microsoft's new tools treat AI agents as potential insider threats, continuously assessing their risk and restricting their access when something changes. The Learn page says that as autonomy increases, so does the potential impact of misalignment, misuse and compromise.
What Microsoft is proposing
Gallot's remedy is continuous supervision. Security teams would need to understand in real time what agents are doing and what risk those actions create. They would then adjust the agents' ability to act accordingly. She says this requires "Guardian Agents," which she calls an established industry term. Her description is of agents that watch and moderate every action of every agent before it happens, around the clock.
She breaks an agent into four parts:
- A model.
- A harness that orchestrates its work.
- An action space of tools and resources.
- A runtime where it executes.
Protection, she says, has to span identity, permissions, data, endpoints, network, cloud and runtime.
The proposed control flow
The post maps the Project Perception stack onto the insider problem in three steps:
- Sensors, signals and actuators. Signals from identity, data, cloud, endpoint, network and runtime sensors are used to discover agents. Each discovered agent is brought under management with an identity, a container, and a set of policies and permissions.
- Context. Those signals feed a dynamic calculation of the risk tied to what an agent is attempting to do.
- Harness, agents and models. Based on that risk, a team of Guardian Agents that includes green and blue agents supervises every action and responds "surgically" as risk rises.
The phrase Gallot uses for the overall goal is deterministic controls on non-deterministic intelligence. In plain terms, you can't predict what the model will do, so you enforce hard limits around it.
Guardian Agents: what is confirmed and what isn't
The Microsoft post itself only describes Guardian Agents as a vision. It doesn't say they are a shipping feature. A report from GeekWire, published the same day, adds some detail. According to GeekWire, the features were announced Monday as part of Microsoft 365 E7, the company's top-tier bundle of workplace software and AI tools, and its Project Perception security system. GeekWire also says Microsoft is adding "Guardian Agents" to Project Perception, and the new agents can investigate why another agent's risk changed and recommend or take steps to contain it.
That is press reporting on an announcement. Nothing I reviewed spells out availability dates, licensing terms, or which agent types are covered. Treat the claim about universal, every-action, real-time supervision as an aspiration until Microsoft documents it.
What Project Perception is today
Project Perception was introduced in a July 27, 2026 Microsoft post as an agentic security system. It combines signals, security context, models and specialized agents. Three classes of agents work together:
- Red team agents look for potential paths to compromise before attackers can exploit them.
- Blue team agents investigate and decide what represents meaningful risk.
- Green team agents take corrective action and strengthen defenses.
Microsoft's July post describes a stack of signals and sensors, security context, models, a harness, agents and actuators. The context layer is a continuously updated picture of assets, identities, relationships, risks and activities, meant to give agents a shared, near-real-time view of the environment.
The July post said the system would enter public preview on August 3. Microsoft Learn documentation currently describes something narrower. It says Project Perception is in a Limited Public Preview, available to a small, invitation-only set of customers for a defined preview window before broader availability. The same pages warn that prerelease information may change substantially. A partner write-up from CyberOne also describes access to Project Perception as managed through restricted preview programs. If you read "public preview" in the July announcement and assume you can switch it on, check your tenant first.
What the documentation says you can do
The Learn pages place Project Perception in the Microsoft Defender portal. The main sections are Overview, New Chat, Sessions, Agents and Playbooks. Documented capabilities include:
- Viewing enabled agents, enabling or disabling them, and configuring agent identity, roles and custom settings.
- Controlling which users can run or view agent sessions.
- Delegating work through reusable playbooks or through natural-language chat.
- Monitoring current and recently completed sessions.
Supervision is the documented part most relevant to Gallot's argument. Agents can pause and set a session to "Waiting for input" when they need approval for a significant action. Microsoft gives examples like disabling a user account or isolating a device. They can also ask for more information or for guidance on which approach to take.
Reviewers can then:
- Approve the action, after which the agent proceeds.
- Reject it, optionally with a reason. The agent skips that action and continues with other tasks.
- Suggest an alternative, such as isolating the device instead of disabling the account. The agent evaluates feasibility and, if it can comply, produces an updated plan and asks for approval again.
- Stop the session. This terminates ongoing work, can't be undone and prevents the session from being resumed.
Microsoft's docs also advise rejecting sparingly, since frequent rejections may point to a configuration problem. They say agents with high approval rates and low error rates might be trusted with fewer approval gates.
These controls govern Project Perception's own agents doing security work. Nothing I reviewed shows that this approval workflow automatically governs arbitrary agents built elsewhere in an enterprise. That extension is the vision in Gallot's post.
The "why" problem and chain-of-thought transparency
The most forward-looking section of the post is about intent. Gallot says security systems can reliably observe agent actions today. She wants controls that can also ask why an action is happening and whether it fits the intent of the task. Getting there, she argues, requires transparency into the model itself, including "thinking and chain of thought tokens," and not only input and output tokens. She says model transparency will not replace containment, but will make it smarter.
This is a proposal, not a shipped capability. There are good reasons for readers to stay skeptical:
- Reasoning traces from a model may not faithfully reflect what drives its behavior. That is a general industry caveat, not something Microsoft's post addresses.
- Access to reasoning tokens depends on model providers choosing to expose them.
- Microsoft's own technical guidance leans on things you can enforce today, like logged plans, tool calls, decisions and outcomes, plus deterministic safeguards.
In other words, intent-aware security is an interesting direction, but the practical protection still comes from boundaries.
A practical checklist drawn from Microsoft's guidance
Microsoft Learn's "Secure autonomous agentic AI systems" pattern describes a defense-in-depth approach that assumes any single layer can fail. It's a useful baseline whether or not you ever touch Project Perception. The controls it recommends include:
- Give agents their own identities. Assign each agent a unique, verifiable identity so role-based access control can be enforced, and keep lifecycle governance on those identities.
- Start from zero permissions. Begin with no permitted actions and add capabilities by role and risk.
- Treat agents like microservices. Use isolated permissions and narrowly scoped tool access to limit blast radius.
- Define explicit action schemas. Spell out allowed actions, required inputs, risk levels, execution constraints and logging requirements.
- Enforce human review through orchestrator logic. For high-risk or irreversible actions, don't leave the decision to the model's own reasoning.
- Filter inputs and outputs. Treat retrieved content as untrusted and block indirect prompt injection.
- Log plans and tool calls. Capture plans, tool calls, decisions and outcomes, and watch for anomalous behavior or repeated bypass attempts.
- Govern model versions. Track versions, review updates and validate changes before deployment.
- Red team continuously. Test for prompt injection, intent breaking and unsafe tool selection.
- Avoid over-capable models. Where a simpler or more constrained model meets the need, prefer it.
The same page maps these controls to Microsoft products. Agent 365 provides inventory, governance and access boundaries. Foundry provides guardrails, content filters, abuse monitoring and red-teaming tools. Entra provides identity, conditional access and RBAC for agents. Purview handles data classification and policy enforcement. Defender and Sentinel cover posture, correlation and response, and Azure Monitor with Application Insights covers telemetry.
The page also lists trade-offs honestly: more engineering effort, added complexity, friction from human oversight, and ongoing operational cost for governance and observability.
Analysis: a good frame, with a vendor-shaped conclusion
Gallot's framing is persuasive on one point. Overprivileged agents with broad data access are a real governance gap, and treating them like insiders (identity, least privilege, monitoring, an off switch) uses mature security thinking. Anyone who has run an insider-risk program will recognize the pattern.
Readers should also weigh a few caveats:
- It's a vendor blog post. It ends with a call to start with Project Perception, and its own product is the proposed answer.
- "Every action of every agent, before it happens, 24/7" is a very high bar. Pre-action mediation of that scale raises questions about latency, coverage of third-party agents, and false positives. The materials I reviewed don't address these.
- Agents supervising agents adds a layer to secure. A Guardian Agent is itself an agent with privileges. The post doesn't discuss how those would be protected or audited beyond the traceability it promises.
- The incidents are unspecified. The post cites a growing number of publicly disclosed AI safety incidents without naming them, so readers can't evaluate the evidence behind that framing.
- Preview limits matter. The Learn pages describe an invitation-only preview, so most organizations can't deploy this today.
What admins should do now
You don't need Project Perception to start acting on the insider framing. A reasonable order of operations:
- Inventory every agent running in your environment, including ones on employee machines and those built by business units.
- Give each one an identity and review its permissions against what its task requires.
- Identify the actions that are irreversible or high-impact, and route those through deterministic human approval.
- Turn on logging for plans and tool calls, and decide who reviews it.
- If you're in the Project Perception preview, rehearse the approve, reject, alternative and stop workflow before you need it in an incident.
Gallot's closing line is that there shouldn't be a choice between innovation and safety. Whether Guardian Agents can deliver that promise at scale is unproven. The underlying advice to inventory your agents, limit their privileges and keep humans in the loop for consequential actions is sound.