AI agents, AI-assisted approvals and automated change

Why this matters

Lesson 25 was about AI that drafts: a script, a report, a ticket update, each of which a person reads before anything happens. This lesson is about AI that does. An agent that can open a firewall change, quarantine a host, rotate a key or roll back a deployment is no longer producing text for review. It is producing changes to production, and every question change management exists to answer (who decided, on what evidence, and how do we undo it) has to be answered for a decision-maker that is a model.

The appeal is real. A security team that triages thousands of alerts, patches across a large estate and processes a steady stream of access and firewall requests has more routine change than people. Agents and AI-assisted approval can absorb the routine part, and the gain is measured in hours of exposure removed: the malicious domain blocked in seconds rather than after the morning stand-up.

The risk is just as concrete. A model that misreads an alert can isolate the payroll server on payday. A model that reads attacker-controlled text, such as a ticket body, an email or a commit message, can be steered by it. And a change made by an agent at three in the morning, with nobody watching and no record of why, is the kind of incident that ends with nobody able to say what state the system is supposed to be in.

The exam angle is consistent. Scenarios describe an automation that is useful and slightly too free, and the right answer is rarely "remove the AI". It is usually a bound: a narrower tool, an approval step, a tested rollback, or a log that would have let somebody reconstruct what happened.

The lesson

AI agents that act on systems, and the guardrails an operator puts round them

An AI agent is a model running in a loop: it receives a goal, decides on an action, calls a tool, reads the result and decides again until it judges the goal met. In security automation the tools are the interesting part: the endpoint platform's isolate call, the firewall's rule API, the identity provider's disable-account call, the ticketing system and the email gateway.

Lesson 12 covered how an agent's identity, credentials and API reach are scoped. That is the foundation and it is not repeated here. This section is about the operational guardrails an operator adds on top, because a correctly scoped agent can still do the wrong thing with the access it legitimately holds.

• A tool allow-list per task. A phishing-triage agent needs to read mail headers, look up reputation and quarantine a message. It does not need the delete-mailbox call even if the API exposes one. Fewer tools means fewer wrong turns as well as less blast radius.
• Dry-run or plan mode. The agent proposes the exact set of calls it intends to make, with arguments, and a person or a policy engine approves the plan before execution. This turns a stream of actions into one reviewable artefact.
• Blast-radius limits. Caps on how many hosts may be isolated, accounts disabled or rules changed in one run or one hour. A legitimate run rarely needs to isolate forty machines; a confused or manipulated one might try.
• Protected targets. Domain controllers, the identity provider, break-glass accounts and the logging pipeline are excluded from autonomous action whatever the agent concludes.
• Treating tool output as untrusted input. An alert description, a ticket body or a fetched web page can carry instructions. The agent's prompt template should mark such content as data, and no instruction found inside it should be able to widen what the agent may do. This is indirect prompt injection from lesson 17, met from the operator's side.
• A kill switch. One control that stops every running agent and revokes its session, tested before it is needed and owned by the on-call engineer.
• Time-boxed effects. Where possible an agent's action expires: a block for twenty-four hours, an isolation pending review. A forgotten action then reverses itself instead of persisting.

AI-assisted approvals inside change management

Change management already has a structure: a request describing what will change, why, the risk, the test evidence and the backout plan; a classification (standard, normal or emergency); and an approval, from a change advisory board for significant changes or a delegated approver for routine ones. AI fits into that structure at several points without replacing it.

What a model does well in the approval path:

• Completeness checking. Does the request have a backout plan, a test result, a maintenance window and an owner? Rejecting incomplete requests early saves the board's time.
• Summarising and comparing. Condensing a long change into what actually differs from the current state, and flagging conflicts with other changes in the same window.
• Risk scoring. Recommending a classification from the systems touched, the history of similar changes and whether the change hits a protected asset.
• Policy matching. Checking a firewall request against the documented rule standard, for example that no rule may open a management port to the internet.
• Approving pre-defined standard changes. A standard change is pre-approved by definition. A model can verify that a request genuinely falls inside the standard change's criteria and let it proceed, which is safer than a human clicking "approve" on the four-hundredth identical request.

What it must not do:

• Be the only approver of a normal or emergency change. The model's recommendation is evidence for the approver, not the approval. A person remains accountable.
• Approve changes its own agent proposed. If the same automation both raises and approves a change, separation of duties has gone, whatever the technology.
• Trust the request text. The requester writes the description. A sentence in it saying the change is low risk and pre-approved is a claim to be checked against the actual diff, not an instruction. The approving model should assess the change itself (the rule, the configuration, the code) rather than the narrative around it.

The failure scenario to recognise is quiet: approvers start accepting the model's recommendation without reading the change, approval rates drift towards one hundred per cent, and the board has become a rubber stamp. That is overreliance, and the control is measurement: sample approved changes, compare the model's risk score with what actually happened, and watch for a fall in challenges.

Automated deployment and rollback, and proving the rollback works

Automated deployment pushes a change through stages with checks between them: deploy to a small slice, watch health signals, widen, watch again. Automated rollback reverses the change when a signal crosses a threshold: error rates, latency, failed health checks or, for a security control, a sudden fall in legitimate traffic after a new blocking rule.

AI contributes in two places. It can judge health more finely than a static threshold, recognising that a spike in errors matches a pattern seen before a real failure rather than ordinary noise. And an agent can carry out the rollback itself, including steps that were never scripted. Both help, and both mean the rollback decision now rests on a model's judgement, so the thresholds that trigger it should still be stated, logged and reviewable.

The examinable point is that an untested rollback is a hope, not a control. Proving it works means:

• Rehearsing it. Every deployment to a test environment also exercises the rollback, and the restored state is compared with the original.
• Capturing the prior state before the change. The agent records the exact configuration it is about to replace, so rollback restores a known state rather than reconstructing one from memory.
• Knowing what cannot be rolled back. A database schema change that drops a column, a deleted record, a revoked certificate already distributed, or a password reset that has been emailed: none of these reverses by redeploying the previous version. Changes with irreversible parts need a different pattern (expand first, contract later) and a human approval, as lesson 12 required for irreversible agent actions.
• Testing the trigger as well as the mechanism. A rollback that works when invoked but never fires, because its health check was pointed at the wrong service, fails exactly when it is needed. Planting a deliberate failure in test and confirming the rollback fires is the proof.

Logging and accountability for actions an agent took

When an agent changes production, the log has to answer more than a human change log does, because "what was it thinking?" has an answer that can be recorded. Lesson 15 covered the fields a model interaction needs and how logs are protected; for an agent acting on systems the record of each run should also hold:

• the goal or trigger that started the run, such as the alert identifier or ticket number;
• the model and prompt version, so behaviour can be reproduced;
• the context it was given, including retrieved documents and tool outputs, because those are where an injected instruction would have come from;
• every tool call with its arguments and result, in order;
• the identity it acted as, which should be the agent's own, never a shared administrator account, so its actions are distinguishable from people's;
• who approved any step that needed approval, and what they were shown;
• a correlation identifier joining the run to the change record and to the target systems' own logs.

Accountability does not transfer to software. Every agent has a named human owner who answers for its configuration, its permissions and its outcomes, in the same way a service account has an owner. When a scenario asks who is responsible for an agent's harmful action, "the AI" is never the answer; the owner who set its bounds, or the approver who accepted its plan, is.

The logs also feed improvement. Reviewing a sample of agent runs, including the ones that went well, is how an operator discovers that the agent has been taking a risky shortcut that has not yet caused harm.

Choosing how much autonomy a scenario's task can safely have

Autonomy is a dial, not a switch. Four settings cover most designs:

1. Suggest. The agent recommends; a person acts.
2. Act with approval. The agent prepares the exact action; a person approves it before execution. This is human-in-the-loop.
3. Act and notify. The agent acts, tells a person at once, and the person can reverse it. This is human-on-the-loop.
4. Act within bounds. The agent acts autonomously inside defined limits, with review after the event.

Lesson 25 asked where automation must stop and a person decide; this is the same question asked of an agent that acts. The setting follows from properties of the task, and a scenario usually gives them away:

• Reversibility. An action that expires or rolls back cleanly can sit higher on the dial than one that destroys data.
• Blast radius. One mailbox is not one domain.
• Verifiability. If the agent's conclusion can be checked automatically (the hash is on the blocklist, the certificate has expired) autonomy is safer than when the conclusion is a judgement call.
• Time pressure. Containment of active ransomware may justify act-and-notify where a slower threat would not.
• Exposure to untrusted input. An agent whose decisions are driven by attacker-controllable text deserves less autonomy than one working from internal telemetry.

Worked examples. Blocking a domain that appears on two threat feeds, for twenty-four hours, is a good candidate for act within bounds. Isolating a single workstation showing ransomware behaviour suits act and notify. Disabling a senior executive's account on the strength of a behavioural anomaly suits act with approval. Deleting data, changing the identity provider's configuration or modifying the agent's own permissions stay at suggest, or out of scope entirely.

A design should also be able to move down the dial: an agent whose error rate rises, or whose environment changes, is stepped back to approval until it earns its autonomy again. Lesson 31 returns to autonomous systems as a business risk.

What the exam is really asking

Most scenarios here reduce to one of four gaps. An agent did something harmful: look for the missing bound (tool allow-list, blast-radius cap, protected target). An approval was waved through: look for the human who should have been accountable, or the request text that was trusted. A change could not be undone: look for the untested rollback or the irreversible step that skipped approval. Nobody can explain what happened: look for the missing run log or the shared identity.