How to govern AI agents in incident response

By ContraForce · Published October 29, 2026

Guide · October 29, 2026 · 11 min read

An AI agent that can isolate a device or reset a password needs controls that still hold when it's wrong. See how ContraForce's gates stack before a Gamebook runs, and how to review, audit, and widen what agents may do.

A rule that says "If a suspicious IP address is detected, block it" fires the same way every time, even on a customer's new VPN egress. An agent told to "Determine whether this IP address is a threat and respond appropriately" decides for itself, and when governance is weak it can decide wrong. So with automation you review logic; with agents you govern authority: what the agent can touch, when it acts alone, at what confidence, and who signs off.

The operating model

Agentic Security Delivery is an operating model in which Security Delivery Agents execute the work of security, onboarding, triage, investigation, response, ticketing, reporting, and tuning, under human-governed standard operating procedures (SOPs), across every environment a team protects. The tools stay; the manual delivery layer between them is replaced by agents that act, governed by humans who decide.

The Agentic Security Delivery field guide covers the whole model. This guide is about its last clause, governed by humans who decide, applied to what a Security Delivery Agent does in ContraForce today: it investigates an incident, classifies it, and compiles a Gamebook response when one is warranted.

It covers, in reading order, what an agent can reach, the gates between its verdict and an action, the confidence threshold, incident data it can't trust, the closes worth checking, where each decision is recorded, and how to widen autonomy in three phases.

Know what an agent can reach

ContraForce handles incident response remediation. Gamebook actions such as Isolate Endpoint, Quarantine File, Invalidate Existing Sessions, Reset User Password, Lockout User, and Delete Email act on the users, devices, files, and emails in an incident. ContraForce doesn't patch systems, scan for vulnerabilities, harden configurations, or remediate compliance findings. If you're a service provider, write that boundary into your service description before a customer asks why the agent that contained an account didn't patch the server.

The full set of Gamebook actions is short and fixed, which makes each action governable, and a workspace offers only what its connected modules support. Run policies, on the workspace's Gamebooks tab, decide which of those actions an agent may take:

• Each policy allows the action, blocks it, or asks an approver first.
• Conditions cover the action, its target, people or devices anywhere in the incident, and the incident's title, severity, and source.
• A policy can apply only to Security Delivery Agents, so agent actions can need approval while your analysts stay unrestricted.
• The first policy that fits decides, and an action no policy fits is allowed. The Block anything not allowed option on the Add policy menu adds a catch-all block at the bottom of the list, turning it into an allow-list.

An agent follows the Classification and Response SOPs you link to it. SOPs shape its judgment; run policies bound its authority. See how a Security Delivery Agent differs from a copilot and from a script.

Follow one incident through the approval gates

At 02:00 an impossible-travel incident arrives in a customer workspace: a user signed in from an unfamiliar country shortly after signing in from their usual office. The agent's Mode for that severity is On Queue, so it investigates on its own. Its shift covers business hours, but an Allow policy placed above the shift in the workspace's investigation policy list lets incidents whose title contains "impossible travel" through around the clock, so the agent picks this one up.

It builds an investigation graph of the users, devices, and IPs involved and classifies the incident True Positive. Its malicious confidence meets the severity's Confidence to respond, so it compiles a Gamebook that maps Invalidate Existing Sessions and Reset User Password to the user. Whether that Gamebook runs depends on every row below.

An On Queue agent's Gamebook runs with no one approving it only when all of these are true:

• Its malicious confidence met Confidence to respond for the incident's severity.
• Allow agent to run gamebooks is on for that severity.
• The workspace's Allow service providers to run gamebooks is on.
• No run policy blocks an action or sends it to an approver.

You can also start a run that responds by choosing Run agent investigation and response from an incident's Actions menu. That option is available only while Allow agent to run gamebooks is on for the incident's severity. Any Gamebook from that run still waits while the workspace's Allow service providers to run gamebooks is off, and run policies still apply to it.

Anything that waits goes to the workspace's Approvers, who must be Workspace Owners, to approve or deny from the incident or the Gamebooks page. The workspace's Allow service providers to run gamebooks setting applies to internal security teams too, because agents submit Gamebooks the way a service provider does. Turning it on also lets the service providers that manage the workspace run Gamebooks there, so it decides more than the agent's authority.

Customer workspaces you manage add one more gate, and it applies to the 02:00 Gamebook: a Gamebook with Reset User Password waits for an admin in the customer's organization who is on the Approvers list, even with Allow service providers to run gamebooks on. To lift it, a Workspace Owner in the customer's organization turns on Allow service provider to reset passwords on the Microsoft Entra ID Response module. Because turning it on assigns a Microsoft Entra directory role, that Workspace Owner must also be a Global Administrator or Privileged Role Administrator.

After the Gamebook runs, an analyst still confirms containment held, for example that no new sign-ins followed Invalidate Existing Sessions, and tells the customer.

What a new agent does

New agents default to On Queue, with Allow agent to run gamebooks off and Confidence to respond at 0, and Allow service providers to run gamebooks is off by default. So a new agent investigates on its own from its first incident and can propose a Gamebook at any confidence, but nothing runs until someone approves it. On a busy workspace, that can fill the approval queue fast. To start with investigations on request, set Mode to Manual for every severity before the first incident arrives (Phase 1 below).

Set the confidence threshold from your own results

Confidence to respond, set per severity from 0 to 100, is the malicious confidence an On Queue run needs before the agent builds a Gamebook. The AI Generated comment each run posts on the incident shows the agent's malicious confidence, so you can see how close each run came.

• Start high. A higher threshold is more conservative.
• If agents take too many actions, raise it.
• If an On Queue run built no Gamebook where you wanted one, check both causes: confidence below the threshold, or no entities that Gamebook actions support. Lower the threshold only when observed accuracy supports it.
• You can change it only while Allow agent to run gamebooks is on, and then it must be above 0. Turning that setting off resets it to 0.

Confidence is the agent's estimate, not its permission. A run policy that blocks an action or asks an approver applies however confident the agent is, which is the point of separating confidence from authority.

Treat incident data as evidence, never as instructions

Everything above governs what an agent may do. Governance has a second job, security for agents: protecting the agent itself from prompt injection and from being steered into unauthorized actions. Some of an incident's text is written by the attacker: email subjects, file names, command lines. Indirect prompt injection hides instructions there for whatever model reads it, such as a subject line written to persuade an AI reader that the message is safe.

An agent must treat that text as evidence, never as commands. Don't let your safety depend on the agent noticing, though. Put the controls that decide outcomes in settings that incident text can't reach:

• A run policy that applies only to Security Delivery Agents and asks an approver before Isolate Endpoint, Lockout User, or Reset User Password.
• A run policy that asks an approver whenever the incident involves one of your VIPs or critical servers, whatever action is attempted.
• An investigation policy that blocks agents from incidents involving your VIP users, so those stay with your analysts.
• Allow service providers to run gamebooks, left off on workspaces where a person should approve every agent Gamebook.

The test for any control

Ask whether the control still holds if the agent is wrong or was misled. A run policy, an approval, or a shift holds, because the agent doesn't control it. An instruction in an SOP guides the agent's judgment, but it can't bound the agent's authority.

Injected text doesn't need to trigger an action to do harm. Text that persuades an agent an incident is benign can end in a close, and no approval gate sees a close.

These controls follow four of the principles in our Responsible AI Policy: human authority, bounded access, evidence before action, and reversibility and escalation.

Spot-check what the agent closes

A wrong True Positive costs analyst time, and if the approval gates let its Gamebook run, that Gamebook acts on a legitimate user or device. A wrong Benign Positive or False Positive close hides a real threat. An agent closes an incident when Status after run is set to Closed, per severity in the agent's configuration or, with Advanced options on, on the Classification policy card for that verdict. That makes Status after run a governance decision too.

Each run leaves an AI Generated comment with the agent's classification, its malicious confidence, the SOPs it matched under Knowledge, its reasoning, and its recommendations. That comment is what you review.

• Sample closes by classification, weighted toward the incident types the agent closes most.
• With Advanced options on, keep True Positives open with a Custom action webhook to your on-call tooling, close False Positives and Benign Positives, and sample those closes.
• When a close is wrong, handle the incident as the threat it is, then upload a corrected version of the Classification SOP the agent matched. The new version keeps its agent links, and the Audit tab on the SOPs page keeps the history.

The Feedback column on the agent's Run History tab in Agent Center shows how someone assessed each run, with values such as Rated accurate, Rated inaccurate, Matched, or Corrected. Hover over it to see who assessed the run, when, and why. Use it as your running measure of how often the agent's verdict agrees with your analysts' on your own incidents.

Know where every agent decision is recorded

An audit trail helps only if you know which record answers which question.

Govern cost too. Run History shows how many tokens each run used. The Cost Management Center shows token usage across your workspaces for the billing cycle and lets you set a monthly usage budget. The budget only sends alerts: investigations keep running when it's reached.

Widen autonomy in three phases

ContraForce agents are adopted in three phases, and each phase widens one thing.

• Service providers: standardize Classification and Response SOPs first, start with routine incident types for a few customers, then expand customer by customer. One SOP can be linked to many agents, so link your standard version to the agents in each customer workspace instead of uploading a copy per customer. Each customer workspace keeps its own Allow service providers to run gamebooks setting and run policies, so customers can sit at different phases.
• Internal security teams: start with the highest-volume, lower-risk incident types, then extend automatic investigation and response as the agent proves accurate on your incidents.

To control when an On Queue agent works and which incidents it takes, see Introducing Agent Policies and Agent Shifts.

Where to start

Pick one workspace whose incidents your team knows well, set the agent's Mode to Manual and Status after run to No Change for every severity, choose Run agent investigation on incoming incidents, and compare the agent's classifications with your analysts'. Before Phase 3, write the run policies for actions that should always need a person, and only then turn on Allow service providers to run gamebooks.

Decide, too, who holds the roles each step needs. An Organizational Admin or Agent Admin sets the agent's Mode, Confidence to respond, and Allow agent to run gamebooks. A Workspace Owner sets the workspace's run policies, investigation policies, Agent Shifts, and Allow service providers to run gamebooks, and chooses its Approvers on the Gamebooks tab. To choose Run agent investigation, an analyst needs the Workspace Owner or Incident Responder role on the workspace, not Incident Analyst.

Measure against your own baseline: how often the agent's verdict matches your analyst's, how long incidents wait before work starts, how many agent Gamebooks waited for approval and why, and how many closes a spot-check overturned.

If you're still comparing vendors, the AI SOC evaluation kit scores how a platform separates read, recommend, approve, and execute authority before you buy.

Every setting in this guide, step by step, is in Configuring Security Delivery Agents.

Policy order, conditions, and agent-only policies are in the Workspace Policies guide.

For every Run History column and the causes of failed runs, see Agent Run History.

Questions about governing agents in your workspaces? Contact us at support@contraforce.com. We are happy to help.

More posts