When AI Handles Your Defences, Who Signs Off?

The range of work handed to AI agents is widening from "look into it" to "fix it." Security is no exception: products have appeared that not only find threats but carry out the remediation. This module takes that shift as its subject and works through, in concrete steps, how a Japanese company operating in the Philippines should decide how much to let a system fix on its own, and where a human takes over.

According to the published material, products of this kind are built from several agents with distinct roles: one that probes for weaknesses the way an attacker would, one that investigates threats and sets priorities, and one that carries out remediation and strengthens defences. They use a purpose-built security model and are currently at the preview stage. What deserves attention is the condition stated alongside all of this. Every high-impact action stays under human sign-off, and the defenders set the objectives and the guardrails — two points made explicitly, with decisions described as scoped, traceable and replayable. In this module we work through that thinking in Parts 1 to 4, applying it to your own situation.

Part 1: Read → Consider the Implications for Your Company

Three points stand out in the published material.

Point	Detail
Roles are separated	One agent probes for weaknesses, one investigates and prioritises, one executes the fix
High-impact actions require human approval	The provider designs on the assumption that it does not complete on its own
The defender sets objectives and limits	Deciding what to achieve and what to forbid remains the work of the company using it

Step 1: Pre-Reading (3 min)

Before you read, consider how this applies to your own company.

Among the actions AI or other tools currently perform automatically, which ones change your production environment?
If one of those actions were wrong, who would notice, and when?
Have you written down which actions you would say require human approval?

Step 2: First Reading (10 min)

The following is a fictional internal memo, written for this module with a Japanese company in the Philippines as the subject, based on publicly available information.

Internal memo: A product that hands our defences to AI, and the line we need to draw

A product that hands security operations to AI agents has entered preview. Three points deserve attention.

First, the roles are separated. The agent that probes for weaknesses, the one that investigates and prioritises, and the one that carries out remediation are kept distinct. Rather than one agent doing everything, responsibilities are divided.

Second, "high-impact actions stay under human sign-off" is stated explicitly. The provider has designed the system so that it does not complete such actions on its own. This should be read not as a limitation but as a condition for this kind of system being usable in a company at all.

Third, it is the defending side that sets the objectives and the guardrails. The product does not arrive with a ready-made framework for judgement; the company using it configures what should be achieved and what is prohibited. In other words, drawing the line remains our work.

Applied to our own situation, the issue is not confined to security. We already have AI performing work across several business processes. We have not written down which of those actions change our production environment, or whose approval they require.

The implications for us are threefold. First, compile a list of the actions AI and other tools carry out automatically. Second, set the criteria for which of those count as high-impact. Third, decide who approves them and how the record is kept.

Source: Project Perception — Microsoft Security

Note: The business scenario above is a fictional internal memo created for learning purposes on the basis of publicly available information. Product specifications and availability may change, so any adoption decision must rest on primary sources and specialist confirmation.

Step 3: Comprehension Check (5 min)

What is each of the three types of agent described as doing?
What condition is placed on high-impact actions?
Who is said to set the objectives and the guardrails — the provider, or the company using the system?

Step 4: Three-Minute Briefing (10 min)

Practise explaining this topic to a management meeting in three minutes. It lands more clearly in this order: what is happening (AI has reached the stage of carrying out defensive work), why it matters (deciding what it may fix on its own remains our job), and what we should do (take stock of what runs automatically, and draw the approval line).

Part 2: Key Terms Explained (for Management)

Agent: a system that, given an objective, works out the steps itself and carries them out. This is what distinguishes it from conventional automation, which performs only the steps it was given.

Separation of roles: the practice of assigning the probing, the judging and the fixing to different agents. It makes it easier to trace where a problem arose than a single combined agent would, and permissions can be separated along the same lines.

Human sign-off: the stage at which a person decides whether an action may proceed before the machine executes it. Placing it on every action stops the business functioning, so the scope has to be narrowed.

Objectives and guardrails: what the system should achieve and what it is forbidden to do, set in advance. The point worth noting is that objectives are set as well as prohibitions.

Traceability and replay: keeping a record of what was done and on what grounds, so that the same path can be followed afterwards. It decides whether a cause can be identified when something goes wrong.

Part 3: Applying This to Your Company

Use these three tests to decide what counts as high-impact.

Test	Actions it catches	Treatment
Can it be undone	Deletion, sending, payment	Put a human approval step in place
Does it leave the company	Anything reaching customers or suppliers	Put a human approval step in place
Does it exceed a monetary threshold	Any amount above the figure you set	Put a human approval step in place

Write down what already runs automatically

Start by listing the actions currently carried out automatically in your company. Not only in security. Registering invoices, updating stock, replying to customers, granting permissions — the actions AI and other tools complete without a person checking are more numerous than most companies expect.

It is not unusual for these to have been introduced by different departments, with nobody holding the full picture. Without a list, no further decision can be made.

Define "high-impact" with three tests

Placing approval on every action brings the business to a stop. To narrow the scope, use these three tests.

Can it be undone? Anything that cannot be reversed is high-impact. Deleting, sending and paying all qualify.
Does it leave the company? Anything reaching a customer or a supplier is high-impact, because an error is treated as the company's own words.
Does it exceed a monetary threshold? Anything above a set amount is high-impact. Decide the amount yourself.

Only the actions that meet one of these three should require human approval. Anything meeting none of them can be left to complete automatically.

Assign approvers by function, not by job title

If approvers are defined by job title, work stops when that person is away. Define the role by the work involved, and always name one deputy.

Set a deadline for approval as well. A rule such as "if no approval is given within 24 hours, the action does not proceed" prevents neglected items from quietly going through.

Decide how records are kept, before you start

Records cannot be created after an incident. Design the execution log to capture three things.

What was carried out
On what grounds it was carried out
Who approved it (for actions requiring approval)

With those three, the path can be reconstructed afterwards. Without them, there is nothing to say beyond "the AI did it." This design also carries weight in legal terms: under the Philippine Data Privacy Act, records are expected in some situations for actions touching personal data.

Part 4: Common Failure Patterns (What Not to Do)

Failure 1: Skipping the line-drawing because "it is a major vendor's product"

Even where the provider has designed the system so that high-impact actions require human sign-off, what counts as high-impact is a setting your company configures. Installing the product does not complete the line-drawing. Going live on the default configuration can leave actions that are high-impact for you running automatically.

Failure 2: Placing approval on every action

Erring too far towards caution builds a queue of pending approvals, and approvers begin signing without reading. That is more dangerous than having no approval at all. Narrowing the scope is the condition for approval working.

Failure 3: Fixing the approver as a single person

When that person takes leave or travels, the work stops. When work stops, the front line looks for a way around it, and a path that bypasses approval comes into being. Always name a deputy.

Failure 4: Leaving the record design until later

"Get it running first, records afterwards" produces a system where the only period without records is the period in which the incident occurred. Build the records in from the start; it is far less work than adding them later.

Failure 5: Treating it as a security matter and not telling the front line

The line may be drawn by an administrative function, but it is the front line that hands work to AI. If the exercise is completed inside that function alone, another department will start a similar automation the following month. Share at least the three tests and the list of actions that require approval.

Three Tips for Getting Value from This

Start by building the list. Judgement can come later. Finish writing down what currently runs automatically this week.
Make the tests part of your internal vocabulary. Once "can it be undone, does it leave the company, does it exceed the threshold" are the terms everyone uses, later discussions move faster.
Go to primary sources. Specifications and availability move. Read the provider's own material and the official documentation rather than summary articles.

Bonus: How to Make Use of PH AI Works

Working out which of your actions already run automatically, and where approval should sit, takes time when done entirely in-house. Our free consultation is open to Japanese companies operating in the Philippines and covers taking stock of automated actions and designing the approval boundary. We work on the stage before product selection: deciding what to hand over, and where a person steps in.