Microsoft tells organisations to treat AI agents as insider threats

The warning

Microsoft Security has told organisations to treat AI agents as insider threats ^[1]. The advice follows the company's launch of Guardian Agents, AI systems that watch other AI agents for risky behaviour ^[1].

The parallel is simple. An insider threat is someone with legitimate access who does something harmful, whether on purpose or by mistake. A trusted employee who can approve payments might one day approve the wrong one. An AI agent with the same access could do the same, faster and at scale.

It's like giving someone the keys to the building. You trust them, but you still log who came in and when.

Microsoft says organisations should apply the same controls to AI agents as they do to privileged human users: principle of least privilege, monitoring, anomaly detection and logging ^[1].

Why it matters now

AI agents are moving beyond answering questions. They book meetings, change orders, approve expenses and write to databases. When they act, they leave traces in the same logs as human users, but the volume is higher and the patterns are different.

Under the AI Act, high-risk AI systems must technically allow for automatic logging of events over their lifetime, for traceability and monitoring ^[2]. For systems under Annex III, that applies from 2 December 2027 ^[3]. The regulation says what to log. It doesn't say how you prove the log hasn't been edited.

That question gets harder when the thing doing the logging is also the thing being watched.

What Guardian Agents do

Guardian Agents monitor other agents continuously ^[1]. They look for unusual patterns: an agent accessing data it doesn't normally touch, making changes outside its usual scope or acting at odd times.

The idea is that one AI watches another, flagging risks a human might miss in the flow of thousands of actions a day. Microsoft describes it as a layer of protection when autonomous systems have access to sensitive data and critical functions ^[1].

It's a sensible step. It doesn't, however, answer the question that comes up when something does go wrong: what exactly did the agent do, and can you show it?

The evidence problem

When an AI agent changes a customer's subscription or approves a refund, someone will eventually ask why. The agent's own log is the obvious place to look, but logs kept by the system being monitored are easy to question.

Say a customer claims an agent cancelled an order they didn't ask it to cancel. The organisation's log says the agent acted on an instruction. The customer says they gave no such instruction. Without an independent record, it's one claim against another.

The same problem exists with human users, but AI agents act faster, more often and with less immediate oversight. A person who approves fifty payments in a shift gets tired. An agent that approves fifty payments a minute does not.

What to seal, and when

Here, the thing to seal is each action the agent takes: the instruction it received, the tool it called, the data it touched and the result. Sealing takes a fingerprint of the record, not the record itself, so the details stay in your systems.

Sealing happens as the agent acts, not afterwards. If it books a meeting, the record of that booking is sealed the moment it's written. If it changes a price, the change record is sealed at the same time.

Anyone you share the record with can later check that it's the one created at that moment, unchanged. Internal audit can check it. A supervisor can check it. If it comes to a dispute, the other party or a court can check it.

What it shows is that the record existed at that time and hasn't been edited since, even by someone with administrator rights. What it doesn't do is authorise the action, prove the instruction was legitimate or show that the agent made the right call. It just makes the 'what happened' question shorter.

How it would work

1. Your agent platform sends a fingerprint of each instruction, tool call and result to WitniumChain through the MCP server, the REST API or the SDK.
2. You get a witness ID back, stored alongside the record.
3. When someone questions what the agent did, you share the record and the witness ID. They calculate the fingerprint and check it matches the sealed one.

The content never leaves your systems. The first 2,000 witnesses a month are free. Read the docs at witniumchain.com/docs.

What this means for you

If you're running AI agents with access to customer data, financial systems or anything that can change state, a few questions are worth asking now:

• Can you show, six months later, exactly what an agent did on a given day?
• If a customer disputes an action the agent took, whose record will you rely on?
• When an agent calls a tool or writes to a database, is that logged in a way that would hold up under scrutiny?
• Who in your organisation can edit those logs, and would anyone outside the organisation believe they haven't been?

Microsoft's warning is a recognition that AI agents, however useful, carry the same risks as any other actor with privileged access. Monitoring them is step one. Being able to prove what they did is step two.

What to watch

The AI Act's logging requirements for high-risk systems under Annex III apply from 2 December 2027 ^[3]. Systems under Annex I follow on 2 August 2028 ^[3]. If your agents make decisions about people or handle tasks that would count as high-risk, the clock is running.

Microsoft has not said when Guardian Agents will be generally available, but the fact that the company is building AI to watch AI suggests it expects autonomous agents to become widespread quickly ^[1].

For now, the principle is simple: if you wouldn't let a person do it without a log, don't let an agent do it without one either. And if the log matters, make sure it's one you can stand behind.