An agent operating inside your Microsoft environment sent an email it wasn’t supposed to send, added a meeting to an executive’s calendar that conflicted with a client call nobody knew about, or pulled data from a SharePoint folder it shouldn’t have touched for this particular task.
Nobody approved such actions as they happened. Nobody was watching when they did. You only found out after the fact.
What happens next is a question most organizations have not answered, and the absence of an answer is itself a risk.
The Monday Morning Problem
The Monday Morning Problem
Incident response frameworks are built for human actors. Someone made a decision, took an action, and can be questioned about it. The trail from event to accountability is imperfect, but it exists.
When an agent takes an action, the trail looks different. The actor is synthetic. The intent was encoded in advance by someone who may not have anticipated this specific scenario. The record of what happened exists only if the infrastructure to capture it was built before the incident occurred.
That last part is where most organizations are exposed. Agent observability is only useful if it was running before something went wrong. You can’t reconstruct a decision trail that was never built.
The Monday morning question has two parts: what the agent did, and whether you can prove it.
What a Real Investigation Requires
A meaningful post-incident investigation for an agent action requires more than a log of what happened. It needs to establish the trigger that initiated the action, the parameters the agent was operating under at the time, the human authority on whose behalf the action was taken, and whether any decision points existed where the agent selected among options.
Without that record, you’re assigning accountability based on assumptions. In regulated industries, including financial services, healthcare, and legal services, that's not a defensible position when auditors or counsel come asking.
Microsoft’s Agent 365 includes observability capabilities designed to capture exactly this kind of record. For organizations that have configured them, a post-incident review is a structured process: pull the audit trail, identify where the agent's behavior diverged from its intended parameters, trace the human authority chain, and determine whether the issue was a configuration problem, a parameter definition problem, or a system behavior problem.
For organizations that haven't configured them, the review is a different kind of conversation.
Containment Before Investigation
Before you can investigate, you need to limit the damage. If an agent took an action it shouldn't have, the first questions are operational: Is the agent still running? Does it have access to systems that need to be protected while you assess what happened? You also need to understand the cascading effects, including workflows triggered, data pulled, and communications sent.
This is where the absence of an incident response policy for agent actions becomes acutely painful. Human incident response has playbooks. Agent incidents, for most organizations, do not.
The organizations that handle these situations well have defined, in advance, what happens when an agent behaves unexpectedly: who gets notified, who has authority to suspend agent operations, what the communication protocol is if the action affected external parties, and who owns the post-incident review.
That documentation doesn’t require legal frameworks to mature or regulators to issue guidance. But someone needs to sit down and write it before an incident forces the conversation.
The Unanswered Policy Question
Enterprise HR, legal, and compliance policies were written before agents existed, of course, and most have not been updated. They don’t define an agent as an actor or describe what happens when one takes an action that would get a human employee fired. That absence is an operational risk that typically sits between HR, IT, and legal without clear ownership. No one team has claimed it because it doesn't fit neatly inside any existing function.
After an incident, the question of who is responsible for what the agent did becomes urgent and uncomfortable. The organizations that handle it well are the ones that answered it before they needed to: defining agent authorization explicitly, assigning ownership of agent categories to specific roles, and building the audit infrastructure that makes the post-incident investigation tractable.
Agents are not standing by; they are operating, and someone needs to write the policy before the next incident forces your hand. As any writer will tell you, a first draft beats no draft. Most enterprises are still staring at a blank page.
Author
