Your AI agent can close an alert. Should it be allowed to?

Giving an AI agent access to security tools is increasingly straightforward. Giving a SOC confidence that the agent has completed an investigation is a different problem.

An agent can query a SIEM, inspect endpoint telemetry, look up asset and identity context, read tickets and produce a convincing conclusion. With the right permissions, it can also close the alert.

But tool access does not define what must be established before closure. And a plausible explanation is not the same as a completed investigation.

That distinction is where many approaches to autonomous security operations fall short. They focus on what the agent can do, but leave the agent itself to decide when it has done enough.

A plausible answer can still be an incomplete investigation

Consider an alert for repeated login failures.

The agent finds a recent password-rotation ticket, searches for subsequent successful logins, finds none and concludes that a scheduled job is still using an old password. It closes the alert as benign.

The explanation is coherent. It may even be correct. But several important questions remain:

• Did the ticket refer to the affected account and system, or merely a similar one?
• Did the search cover the full relevant time window and every applicable identity source?
• Were those sources healthy and current at the time of the search?
• Did the agent check for successful access from another source or through another authentication path?
• Did it look for activity that would contradict the benign explanation?
• Was the account privileged, shared or associated with a critical system?

The agent found a reason to stop. It did not necessarily establish that the case was safe to close.

This is not primarily a model-quality problem. A more capable model may search better, reason more clearly and make fewer mistakes. It still needs an external definition of what constitutes a complete investigation — and an enforcement mechanism it cannot reason its way around.

Define the proof required for closure

For each investigation type, the SOC should define the claims that must be established and the evidence required to support them.

For the login-failure case, that definition might require:

• Event sequence. The failures and any subsequent successes for the relevant account, source and destination across a defined time window.
• Identity and asset context. The owner and purpose of the account and source system, their criticality, and whether elevated privileges are involved.
• Evidence supporting the explanation. A password change, maintenance record or other approved activity that matches the account, system, timing and observed behaviour.
• Evidence that challenges the explanation. Checks for unfamiliar sources, unexpected successful access, suspicious follow-on activity and any other conditions required by the procedure.
• Data coverage. Confirmation that every required source was available, healthy, current and capable of covering the relevant systems and period.

Finding a ticket may satisfy one requirement. An empty search result may satisfy another — but only if the query was correct and the underlying telemetry was complete enough for absence to mean something.

Neither should silently substitute for the rest of the investigation.

The library defines the work. The harness enforces it.

Putting a checklist into a prompt is useful, but it is not enforcement. The model can misunderstand it, skip a step, accept weak evidence or decide that the conclusion is already obvious.

An investigation harness moves those requirements outside the model and turns them into conditions evaluated by software.

For every case, the harness should be able to answer:

• Which checks are required?
• Which version of the investigation procedure applies?
• What evidence was collected for each check?
• Does that evidence meet the defined acceptance criteria?
• Were the necessary data sources available and sufficiently complete?
• What remains unresolved or contradictory?
• Is closure permitted, or must the case be escalated?

The agent remains flexible where flexibility is valuable. It can decide how to search, adapt queries to the available tools, recover from failed calls and follow unexpected leads.

What it cannot do is redefine "complete" simply because it has found a convincing story.

The resulting division of responsibility is important:

• The SOC defines what must be established.
• The investigation library expresses those requirements in a versioned, reusable form.
• The agent gathers and interprets the evidence.
• The harness tracks the required checks and controls whether closure is allowed.

Model Context Protocol (MCP) and other integration layers can help agents access tools and operational context. They solve the connection problem. The investigation library and harness solve a different problem: governing what the agent must prove through those tools before it can act.

Absence of evidence is only meaningful when coverage is known

This matters especially when the agent relies on negative findings.

"No successful login found" sounds reassuring. But it could mean that no successful login occurred; that the query used the wrong account identifier; that the time window was too narrow; that the relevant system reports to another source; that ingestion was delayed or interrupted; or that the required telemetry was never collected.

Without evidence-quality and coverage checks, these outcomes can look identical to the agent. A reliable investigation must distinguish between "the evidence supports absence" and "the system was unable to establish whether evidence exists."

The second result is not benign. It is unresolved.

The decision should survive review

An investigation record should contain more than a narrative such as "reviewed — no threat found."

A reviewer should be able to see:

• the procedure and version used;
• every check required for that case;
• the evidence attached to each check and where it came from;
• the query scope and relevant source coverage;
• unresolved or contradictory findings; and
• the exact reason closure was permitted or escalation was required.

This allows an analyst to assess the decision without reconstructing the agent's reasoning from a transcript. It also exposes recurring evidence gaps, weak acceptance criteria and investigation steps that need to change as the environment and threats evolve.

The goal is not to make investigations rigid. It is to make the conditions for acting on them explicit.

From agents that investigate to systems you can trust

Autonomous security operations will not be achieved simply by giving increasingly capable models more tools and broader permissions. The hard part is deciding when an investigation has produced enough reliable evidence to justify an operational decision — and ensuring that this threshold is applied consistently.

That is the layer Oryen is building: a deterministic, versioned investigation system around adaptive AI agents. The agent performs the investigative work. The SOC retains control over what must be proven. The harness ensures that missing, weak or contradictory evidence cannot be converted into a confident closure.

In a SOC, the important question is not whether the agent can reach a conclusion. It is whether the system can show that the conclusion was earned.