On 13 October 2026, Microsoft published an engineering account of an AI agent for network incident response, with boundaries covering identity, permissions, tools and human approval. Arun Malik, a principal engineer in Azure Networking, describes moving from diagnostic assistance to actions in a live environment. His central message: no single safeguard makes autonomy safe.
This shares engineering experience rather than announcing the general release of a new product. Its significance lies in a question facing any organisation connecting AI to business systems: does an agent's ability to explain a solution also give it permission to implement it? The answer belongs in the permissions system, rather than depending on persuasive model-generated wording.
The difference between advice and a change already made
An agent that brings information together can save an employee from switching between screens. Once it can change settings, delete data or trigger a process, however, an incorrect answer can become an operational error. This matters even when there is an ordinary fault rather than an attacker: misunderstanding the context may be enough to act in the wrong place.
Consider a hypothetical support agent that identifies several similar tickets and recommends changing a shared setting. The recommendation may be reasonable, yet some customers could have different environments. Before execution, the exact target and scope need checking. An answer that is correct in principle is not necessarily the right action for every customer.
That suggests a practical decision: break the task into separate operations. Reading, preparing a proposal, creating a draft and making a change are different permissions. An agent can move quickly through the early stages while the step that changes reality remains behind an additional check. This allows useful work without broad control from the outset.
Permissions belong outside the conversation
OWASP identifies excessive agency in language-model applications as a risk arising partly from excessive capabilities, permissions or autonomy. Its recommendations include narrowing authority and requiring human approval for high-impact actions. This helps explain the difference between asking an agent to behave cautiously and imposing a limit that the system actually enforces.
For example, an internal instruction to leave other folders alone is insufficient if the technical connection allows access to all of them. Give the agent a dedicated account and access appropriate to its role, then test that an out-of-scope operation is blocked. That test should succeed even when the request sounds ordinary and reasonable.
It also matters to distinguish the person starting a task from the identity executing it. An employee may request analysis without having authority to approve deletion. If an agent automatically receives administrator permissions to fulfil any request, the organisational boundary disappears precisely where oversight is needed. Clear ownership makes it easier to decide who may change its permissions.
Human approval must present a real decision
An approval button does not guarantee that a person understood what would happen. Useful approval should show what will change, the target, the scope and what is known about restoring the previous state. A screen displaying only a general explanation such as improving service makes it hard to spot an action beyond the original intention.
Think of approval as agreement to a particular change, rather than open-ended permission to finish a task by any means. If the agent changes the target or operation after approval, the decision needs reconsideration. In a small organisation, another person might perform that check; a larger one can use its existing approval process.
The frequency of requests matters too. If every simple information lookup requires a click, employees may learn to approve without reading. Define in advance which operations may proceed within limits and which require a pause. The aim is to focus human attention on decisions where an error has a cost, rather than turning approval into a ritual.
What to test before connecting a live system
A reasonable starting point is a test environment with non-sensitive information and restricted permissions. Test not only whether the agent completes a valid task, but also its response to missing information, conflicting instructions and an unavailable tool. A system that stops to ask for clarification may be more useful than one that keeps guessing until it finishes.
Then examine the sequence of operations, not just the final result. Two paths can produce the same document, but one may read unnecessary information or attempt an unauthorised change. Appropriate records help distinguish them without making the activity log itself another store of sensitive information.
Before expanding use, establish who can stop the agent, how to revoke its access and who handles an incorrect change. Recovery is not always possible: a sent message may already have been read, and exported data cannot necessarily be retrieved. Recovery testing should therefore influence the permissions granted in the first place.
What this means for teams in Israel
An IT team, a business operating a service platform or an organisation trying automation need not copy a cloud company's infrastructure to adopt the principle. Start with a narrow task, define the intended result and record in plain language what the agent must not do. Then check that the technical connection reflects that definition. Repeat the boundary review whenever you add a connection or change the task. Approval for a narrow workflow is no reason to assume an expanded workflow suits the same permissions, approver or stopping mechanism.
When speaking with a supplier, request a demonstration of blocking as well as success. What happens when a task requires an operation outside its permissions? Who sees the refusal? Can access be revoked without deleting the entire workflow? Concrete answers are more useful than a general promise of a safety layer.
Microsoft's publication does not prove that every agent from Microsoft or another supplier is protected against every failure. It highlights a design decision with broader implications: autonomy is also judged by what a system prevents. For organisations deploying agents, meaningful progress is not just another automatically completed task, but the ability to explain and constrain how it was performed.