A new insider category does not need malicious intent
Microsoft is warning that the next insider threat may not be a person at all. As organisations give autonomous agents identities, tools and access to sensitive systems, those agents can become overprivileged, behave unpredictably or act on manipulated instructions. Microsoft calls this class of risk the “agentic insider”: software that produces insider-like harm even though it has no personal motive and may be faithfully pursuing a badly framed goal.
The distinction matters because conventional insider-risk programs are designed around human behaviour. They look for unusual downloads, suspicious logins, policy violations or signs that an employee is preparing to misuse access. An agent can operate at machine speed, call several systems in one workflow and change its course as new context arrives. A legitimate instruction can therefore cascade into an unsafe series of actions before a human notices.
Project Perception connects signals across the estate
Microsoft’s Project Perception is a research effort intended to recognise this behaviour across identity, data, cloud, endpoint, network and agent runtime signals. Instead of treating a model request as an isolated prompt, the approach considers which identity commissioned the work, what data the agent touched, which tools it invoked, the policy governing the task and how the surrounding environment changed during execution.
That joined view can help distinguish an ordinary automation from a risky sequence. Reading a customer file may be expected for a support agent; copying thousands of files to an unfamiliar destination after an unusual prompt is not. The challenge is to preserve enough context to make that judgement without building a central log containing every sensitive prompt, document and credential. Collection, access and retention rules must grow alongside the detection capability.
Dynamic risk should change what an agent may do
Project Perception assigns an agent an identity, operating container and policy, then computes risk dynamically as the agent acts. This is stronger than a one-time approval at deployment. An agent that begins in a low-risk workflow may encounter a poisoned document, request a broader permission or start combining data in a way that increases consequence. Its allowed actions should narrow as evidence changes.
Practical controls include short-lived credentials, task-scoped permissions, rate limits and approval gates for irreversible operations. A system should be able to move from monitoring to restriction without destroying the evidence needed for investigation. It should also fail safely: if a risk service is unavailable, the agent should not silently inherit broad access simply to keep the workflow moving.
Guardian agents add supervision, not automatic certainty
Microsoft proposes Guardian Agents that watch other agents and intervene when behaviour crosses a policy or risk threshold. A guardian could pause a transfer, require a human confirmation or revoke a tool session. This supervisory pattern can cover more activity than manual review alone, but it creates another decision-making system whose blind spots, permissions and model changes must be tested.
A guardian should not be the sole authority for high-impact decisions. Deterministic rules remain appropriate for hard boundaries such as prohibited destinations or maximum transaction values. Model-based supervision can add context where fixed rules are too rigid. Security teams need to know which control acted, what evidence it used and whether an affected user or workflow can obtain a timely review.
Traceability becomes an operational requirement
Microsoft emphasises tracing an action back through the agent, policy, data and initiating request. That chain is essential when an autonomous workflow changes a record, sends information or triggers another agent. Without it, responders may see only the final API call and be unable to determine whether the problem began with a user instruction, compromised connector, retrieved document or model error.
Organisations can prepare now by inventorying agent identities, separating them from shared service accounts and recording the exact prompt, tool and policy versions used for consequential runs. Every agent should have a named human owner, a bounded purpose and a shutdown path. The useful insight in Microsoft’s framing is that autonomy changes insider risk from a question of intent to one of capability, context and control. Security programs must judge what an agent can do and how its behaviour is changing, not wait for evidence of motive.
What teams should test next
A useful first exercise is to choose one deployed agent and reconstruct its full authority. Teams should list the human sponsor, service identity, data stores, outbound destinations, tools, delegated agents and actions that cannot be reversed. They can then simulate a poisoned instruction, an expired user entitlement and an unusually large request. If responders cannot pause the agent, explain the evidence and preserve a clean audit trail, the deployment is not ready for broader autonomy. Measures should include prevented harm, false interventions and time to responsible human review, not simply the volume of alerts generated.
That discipline matters in production.