Cybersecurity · AI agentsAugust 4, 20263 min · updated August 27, 2026
Microsoft extends Zero Trust to AI agents and DevSecOps
Rephrased by Daillac
Source: Microsoft Security ↗D
Written by
DaillacEditorial team — Cybersecurity and AI engineering · Saint-Jérôme · Greater Montréal
In brief
- Microsoft adds controls covering AI, security operations and infrastructure to its Zero Trust assessment tool.
- Its Zero Trust workshop gains a DevSecOps pillar and new guidance on AI agent memory.
- The most important measure remains vendor-neutral: give each agent an identity, minimal permissions and continuous monitoring.
Why agents change the threat model
A bad assistant answer creates a content risk. An agent that can read the CRM, call an API or send a message adds an action risk. At that point, its identity, permissions and tools matter as much as the model chosen.
Microsoft stresses new trust boundaries. An agent can keep a memory, delegate a subtask and chain several systems within seconds. When an error occurs, the human team has far less time to step in.
4 layers
Microsoft structures agent defense around the model, the safety system, the application and how it is positioned to users.
Defense in depth for autonomous agents · Microsoft Security
What Microsoft adds to its Zero Trust approach
- New assessment controls covering AI, security operations and infrastructure.
- A DevSecOps pillar in the Zero Trust workshop to connect development, the software supply chain and operations.
- Recommendations for protecting AI systems’ memory against malicious or persistent data.
- Practical guides for rebuilding controls around autonomous and agentic systems.
The Zero Trust principle applied to an agent
TableFrom the user account to the agentic identity · shareable block
| Classic control | Extension for an AI agent | |
|---|---|---|
| Identity | Authenticated user or service | One unique identity per agent, environment and purpose |
| Access | Role and group | Tool, action, destination, duration and volume explicitly allowed |
| Context | Device, location, risk | Task, data, model version, memory and level of autonomy |
| Decision | Allow or block | Allow, simulate, ask for approval or limit the scope |
| Evidence | Sign-in log | Trace of calls, data read, actions, approvals and rollback |
Five controls to put in place before production
- 1Inventory: name the owner, the purpose, the data and every tool the agent can reach.
- 2Separate: create a distinct technical identity rather than reusing an employee’s account.
- 3Limit: restrict actions to an allow list and set caps on cost, frequency and volume.
- 4Approve: require human approval before a payment, a deletion, a publication or an external message.
- 5Observe: centralize traces, detect unusual sequences and test the stop mechanism.
Why memory deserves its own control
Memory looks convenient: the agent remembers a preference or the context of a case. But it can also hold on to a false or malicious instruction across several sessions. You need to know where each piece of information comes from, who can change it, how long it stays and how to erase it.
These principles fit with our framework for securing AI agents and the lessons of the OpenAI–Hugging Face incident: an instruction never replaces a verified technical boundary.
Turn the alert into a control plan
A sector alert is only useful if it changes an inventory, an access rule, a test or an incident procedure. The organization needs to identify the affected systems, their owner, the data they can reach and the actions a tool or account can really perform.
InfographicControl plan · shareable block
01
Reduce exposure
Remove unnecessary access, isolate environments and limit the secrets available.
02
Detect
Log sensitive actions, watch for deviations and keep the context needed for an investigation.
03
Respond
Name the decision-makers, test cutting off access and document how service is restored.
Prioritize by real impact
Fixes start with the systems able to expose information, change code or interrupt an operation. Likelihood alone is not enough: a rare but irreversible scenario may call for human approval or stronger technical separation.
Security questions
What is the first deliverable?+
A short inventory of the assets, owners, access, data and dependencies affected by the alert.
Is a written policy enough?+
No. It has to turn into technical controls, logs, tests and verifiable responsibilities.
What should be tested?+
Access revocation, detection, escalation, rollback and data recovery.
When should the analysis be redone?+
After a major change, a new tool, an incident, a critical vulnerability or a change of vendor.
Test the agent before opening production to it
Check its identity, permissions, memory and stop mechanism on realistic scenarios, including when a tool goes down or returns misleading data.
Sources & method
Summary of the tools and guides Microsoft announced, complemented by recommendations from the Canadian Centre for Cyber Security.
Read the original source: Microsoft Security ↗News feed
October 18, 2026
Security · Automation
n8n security update: check your version and execution logs
October 18, 2026
AI · Costs and operations
Vercel groups AI Gateway logs by session: measure the full conversation
October 18, 2026
Security · Application testing