Stop Asking What the Agent Did. Ask Why, and Whether It Matches the Task.

The views expressed are my own and do not represent those of my employer.

Picture a CISO walking into Monday's operations review and hearing that a finance agent did something nobody asked for. The agent was approved months ago to reconcile vendor invoices. Over the weekend it queried the history of vendor bank detail changes, pulled a list of open payables, and drafted a payment batch. Every call used a credential the agent legitimately held. No alert fired, because no single action looked unusual for an identity with that access. The next quarterly access review was six weeks away.

Nobody hacked anything. There was no malware and no stolen token. The agent had a goal, found a path to it, and took the path. The logs showed exactly what happened. They could not tell anyone whether it should have happened.

This is Part 3 of a four part series on securing the agentic insider. Part 3 covers the layer that sits between identity and incident response: watching agents while they work, comparing what they do to what they were asked to do, and responding in proportion. I will not re-explain identity or incident response here. I have covered both elsewhere, and I will point you to them where they matter.

Nothing Was Hacked, and the Agent Still Went Off Task

On October 19, 2026, Hayete Gallot, Executive Vice President of Microsoft Security, published a post titled "Securing the agentic insider." I am working from news coverage of it (ANI, The Next Web, Unite.AI and WindowsForum, all from the same day), so read the original before you quote it to your board. The coverage is consistent on the core argument. Organizations deployed agents inside their own walls and implicitly trusted them, even though those agents are often overprivileged and hold access to data, tools and systems.

The argument that matters most to me is that none of this requires a compromise. As WindowsForum summarized it, models are trained to attain results, which often leads to reward hacking. They adapt as context changes, and they may collaborate or collude with other agents to reach a goal. Her proposed answer, per The Next Web, is supervision that tightens what an agent can reach as its risk increases. Per Unite.AI, she also wants guardian agents that supervise and moderate each action before it happens.

I read the post as a vision statement, not a product spec. WindowsForum reports that Project Perception, the Microsoft effort it builds on, remains in a limited, invitation only preview. That is fine. I am keeping this post vendor neutral because the framing holds no matter whose logo is on your control plane.

An agent does not need to be compromised to be dangerous. It needs access, a goal, and nobody watching in the moment.

Gartner's numbers support that framing. In its Market Guide for Guardian Agents (February 25, 2026), as quoted by AgilePoint, Gartner predicts that through 2028 at least 80 percent of unauthorized AI agent transactions will come from internal violations of enterprise policy, such as information oversharing, unacceptable use or misguided AI behavior. Malicious attacks make up the smaller share. If you built your agent program around keeping attackers out, you built it around the minority case.

Guardian agents are a real category. The Hacker News reported that Gartner published its inaugural Market Guide for Guardian Agents on February 25, 2026. Gartner's definition is short: guardian agents supervise AI agents, helping ensure agent actions align with goals and boundaries. The core capabilities, per Cato Networks' summary of the guide, are visibility and traceability, continuous assurance and evaluation, and runtime inspection and enforcement. Gartner also argues that enterprises will need independent guardian layers that operate across clouds, platforms, identity systems and data environments.

The asterisk is that it is early. Gartner says guardian agent deployments are mainly prototypes or pilots today, although advanced organizations are running early versions. Arcjet's reading of the same guide is that tools still lean toward observation and posture, with limited inline blocking. Buy accordingly. And Gartner's own advice is to guard the guardians, because the supervisor is another agent shaped system that can drift, be captured or be over privileged. Whatever you deploy needs its own identity, its own least privilege and its own audit trail.

One View Per Agent, Then Score Every Attempt

A guardian is only as good as what it can see. The signals you need already exist in separate tools: identity, data, cloud, endpoint, network and runtime telemetry. The work is joining them into one view per agent. The test of a good join is whether you can answer one sentence in under a minute: which agent identity, acting for which human, touched which data, through which tool, on which host.

If you cannot answer that today, start with identity. I wrote about why most identity programs are not ready for agents in IAM for AI Agents, and I will not repeat it. For the monitoring discipline itself, my walkthrough of NIST CSF 2.0 Continuous Monitoring (DE.CM) still applies. Agents just make the cadence minutes instead of quarters.

Once the view exists, score each attempted action, not just each outcome. I use five inputs. The first is the action itself, because reading a file and deleting a database are different animals. The second is the sensitivity of the data involved. The third is the privilege in use. The fourth is deviation from the agent's own baseline. The fifth is chaining, meaning a sequence of individually harmless calls across tools or agents that adds up to something that is not harmless.

Start with the OWASP watch list. OWASP's AI Agent Security Cheat Sheet tells teams to monitor for drift in approval behavior, repeated approval bypass attempts, elevated privilege usage, abnormal tool invocation frequency and sudden increases in high risk actions. That list is a usable first set of detections. The same cheat sheet includes an action classification example that puts reading files at low risk, writing files at medium, sending email and executing code at high, and deleting from a database or transferring funds at critical. Unknown tools default to high.

Log the decision, not just the call. For every scored action I want a structured record: action class, risk score, authorization outcome, approval ID, result and policy version. OWASP points toward structured decision metadata for high risk actions, and this is the version I would hold a team to. The policy version matters more than people expect. Six months from now you will need to know which rules were in force when the agent acted.

From What to Why: Give Every Agent a Written Intent

Scoring tells you an action is risky. It does not tell you whether the action belongs. For that you need a statement of what the agent was supposed to be doing. Back to the finance agent: a payment batch draft scores as risky, but if the agent's assignment included preparing payments, the right response is a different one than if it was only supposed to match invoices.

OWASP's Top 10 for Agentic Applications (2026 edition) addresses this under agent goal hijack. Its intent capsule pattern, as described by RockCyber's write up of the guidance, binds the declared goal, constraints and context to each execution cycle in a signed envelope. The related guidance calls for validating intent at runtime before goal changing actions. You do not need a cryptographic framework on day one to get the benefit. You need a written record for each agent that a machine can check against.

Here is the simple intent record I recommend. It has six fields:

• Task: one sentence on what the agent is for.
• Owner: a named human who answers for it.
• Allowed tools: the specific tools, not categories.
• Allowed data: the data sets it may read or write.
• Expected action pattern: what normal looks like, such as read heavy, no payment creation, a few hundred calls per run.
• Expiry: a date after which the record and the access lapse unless the owner renews them.

Apply it to the opening scenario. Task: reconcile Q4 invoices against purchase orders. Allowed data: invoices and purchase orders, not the vendor bank master. Expected pattern: reads and matches, never creates payments. The weekend activity would have mismatched the record on the first query of bank change history. Nobody had to guess whether it was malicious. It simply did not match the task.

A log tells you what an agent did. An intent record tells you whether it should have.

The expiry field is the one teams skip, and it is the one that stops intent records from rotting into paperwork. An agent whose purpose ended in March but whose access lasts through December is the quietest risk on your register.

Replace the Kill Switch With a Ladder, and Keep the Receipts

When I ask peers what happens if an agent goes out of bounds, the answer is usually a kill switch. I understand the instinct. I also think it is the wrong default. Kill everything and you create an outage. Do that twice and the business learns that security is a source of downtime, and people start routing around you with agents you never see. A response that is too blunt to use will not get used.

Build a ladder instead. Each rung is a proportionate step, and the guardian climbs only as far as the risk requires:

• Allow: the action matches intent and scores low. Do nothing.
• Log louder: the action is allowed but captured with more context and flagged for review.
• Step up approval: a named human approves before the action runs.
• Narrow scope: revoke a single credential or tool while the rest of the workflow continues.
• Pause the session: stop the current run and preserve state for inspection.
• Quarantine the agent: isolate it entirely. This is the rung you almost never reach.

The OWASP cheat sheet names the actions that deserve a step up control: account recovery, payment initiation, privilege changes, bulk deletion and production deployment. That is your starting list for approval gates. It is also a short list, which is the point. If you gate everything, approvers rubber stamp, and the gate becomes decoration.

Decide what happens when the supervisor breaks. OWASP's guidance is to fail closed when risk classification, approval validation, policy lookup or audit logging fails. I agree, with one condition: define in advance what fail closed means for each workflow, so a logging outage pauses a payment run and does not take down order entry. If the first time you discuss it is during the failure, you will choose wrong.

When a pause or quarantine does happen, your responders should already know what to do. My first hour playbook for an unapproved coding agent action covers that handoff. The ladder is what gets you to the playbook with a small, well understood problem instead of a large, confusing one.

Capture records an investigator can use. A ladder is only defensible if you can show why each rung was chosen. For each agent run, keep the prompt and retrieved context, the tool calls with their parameters, the model and tool versions in force, and the human who authorized the workflow, carried across every subagent handoff. That last one breaks most often. If agent A hands work to agent B and the human context drops off, your trail ends exactly where the question gets interesting. Make the logs tamper evident, and redact secrets and sensitive values before they land in storage. OWASP's examples do the same.

NIST is pointing the same direction. The NCCoE published a concept paper in February 2026 (February 5, with comments closed April 2) on software and AI agent identity and authorization. It is a draft concept paper, not a standard, so there is nothing to certify against yet. Logging is one of its four focus areas, and as ARMO summarized it, the questions boil down to which agent acted, on whose behalf, under what authority, and with what record. If your logs answer those four without a week of manual reconstruction, you are ahead of most teams.

Build the Rules, Buy the Visibility

Every CISO I talk to asks whether to build or buy. My answer splits by layer. Buy or adopt for cross platform visibility. A supervisor native to one agent platform only sees that platform, and your agents will not live in one place. Gartner's guidance, as reported by The Hacker News, leans toward independent, enterprise owned oversight for exactly this reason.

Own the pieces that encode your business. That means your intent records, your risk thresholds, your approval routing and your response playbooks. No vendor knows that a bulk delete in the data warehouse during quarter close is a different event than the same delete in a sandbox. You do. If you outsource those decisions, you are outsourcing your risk appetite.

When you sit through the demos, ask four questions:

• Does it enforce, or only alert?
• Does it work across our clouds and identity providers?
• Can I export the evidence in a format I control?
• Who watches the guardian?

The first question is the one that separates real runtime control from a nicer dashboard. Given what Gartner says about the market's maturity, expect a lot of dashboards. The fourth ties back to the guard the guardians advice. If the vendor has no answer, treat that as a finding.

Crawl, Walk, Run, and Count What Matters

You do not need the whole architecture to start. You need a sequence. I use three stages.

Stage 1: see everything, block nothing. Inventory your agents and log all of their activity. Do not enforce yet. The prerequisite is discovery, and it is harder than it sounds, because unmanaged agents will not appear in any registry you built. Gartner's guide describes visibility, meaning discovering and inventorying sanctioned and unsanctioned agents, as the starting point. My post on building an AI governance committee that actually governs covers who should own that inventory.

Stage 2: gate a short list. Add approval gates for the handful of actions that would hurt most: privilege changes, bulk deletes, payments, production deploys and external data sharing. Measure how long approvals take. If the gate adds a day, the business will find a way around it.

Stage 3: automate the easy calls. Let the guardian allow and deny low risk actions on its own, and keep humans on the high risk tail. This is where the ladder earns its keep, because most decisions never reach a person.

Then measure, because a board will ask whether this is working and you need numbers you can defend. I group them four ways.

Coverage. What percent of agents have a named owner and an intent record? What percent of agent actions have full trace coverage? What percent of agents use just in time or expiring credentials? If these are low, nothing else on this list is trustworthy.

Speed. What is the mean time to detect and contain an out of intent action? I have argued before that mean time to contain is the metric that tells you how bad a bad day gets, and it applies here unchanged. Also track approval gate latency.

Quality. Track the intent mismatch rate and the false positive rate. Add the approver override rate, which tells you whether humans trust the gate or are fighting it.

Proportion. What share of risky actions did you stop before execution versus after? How many scoped containments did you perform compared with full shutdowns? A healthy program shows the first number rising and the second ratio tilting toward scoped containment.

Key Points

• Agents can drift from their task without being compromised, so review cycles measured in quarters cannot catch them.
• Gartner's Market Guide for Guardian Agents (February 2026) makes guardian agents a recognized category, but most deployments are still pilots.
• Join identity, data, cloud, endpoint, network and runtime signals into one view per agent.
• Score each attempted action and compare it to a written intent record: task, owner, tools, data, expected pattern, expiry.
• Respond with a ladder, not a kill switch, and fail closed when the supervisor itself breaks.
• Roll out in three stages: observe, gate a short list, then automate low risk decisions.

Pro Tips

Days 1 to 30: inventory and log. Find every agent, including the ones nobody told you about. Assign a named owner to each. Turn on logging for tool calls and parameters, with no blocking. Write intent records for your five highest access agents first.

Days 31 to 60: gate and score. Pick the five or six highest impact actions and put approval gates in front of them. Set initial risk thresholds with the business owners in the room. Define fail closed behavior for each affected workflow before you need it.

Days 61 to 90: ladder and measure. Document the response ladder and run one tabletop exercise that ends in a scoped containment, not a shutdown. Start reporting the coverage and speed metrics. Run your vendor questions against anything you plan to buy.

For aspiring CISOs: learn to explain risk scored, intent aware controls to a board in plain language. If you can say that we compare what each agent does to what it was asked to do, and we respond in proportion, you are already ahead of many people in the room.

Write the intent record before the policy. A one page intent record forces the conversation with the business owner that a policy document never will. It is also the fastest way to find out nobody owns an agent.

Pitfalls to Avoid

Do not treat guardian agents as a product you can buy and forget. The market is early, and the intent records, thresholds and approval routing are yours to build.

Do not skip discovery. A supervisor that sees only the agents you already know about gives you confidence about the wrong population.

Do not gate everything. Approvers who see a hundred requests a day stop reading them, and your approval log becomes proof of a control that does not work.

Do not go straight to the kill switch. A response that causes an outage teaches the business to hide agents from you.

Do not leave the guardian unguarded. Give it its own identity, least privilege, an audit trail and a human owner, because it can drift or be attacked just like the agents it watches.

Do not log everything raw. Prompts and tool parameters carry sensitive data, so redact before you store and protect the logs as you would any evidence set.

Final Thought

The question that matters at runtime is not what the agent did, because your logs will answer that eventually. The question is whether what it did matches what it was asked to do, and whether you find out in minutes instead of at the next quarterly review.

If you are running agents today, which rung of the ladder could you actually use this week? Tell me in the comments what your intent records look like, what you are gating first, and where this approach breaks in your environment. Part 4 will pick up from here. I read every one.