AI Agents for Security Operations: Read-Only Triage and Reports

An AI agent for a security operations team is most useful when it does the reading and writing around an alert, not the acting. It gathers context, compares the alert with past cases and runbooks, proposes a priority and drafts the ticket or report, while every change to a system stays with a named analyst. Start with read-only access, record everything the agent touches, and add response actions only one narrow step at a time, if ever.

Key takeaways

• Read-only triage, enrichment and report drafting remove most of the repetitive load without giving the agent any power to change a system.
• The agent should propose and explain. An analyst decides, and the decision is recorded next to the agent's reasoning.
• Alert content is untrusted input. Treat text inside logs, emails and tickets as data, never as instructions.
• Response actions, if they are ever allowed, need a short approved list, a human approval step and a clear way to undo them.
• Measure the agent with a fixed set of past alerts and an observable success criterion before widening its role.

What does an AI agent actually do in a security operations team?

In a security operations team, the slow part of an alert is rarely the decision. It is the gathering: which asset is this, who owns it, has it fired before, what changed recently, and what did we conclude last time. An analyst opens several tools, copies fragments into a ticket and writes a summary that the next person has to re-read.

A well-scoped agent takes over that gathering and writing. It reads the alert, queries the sources it has been granted, checks the team's own runbooks and prior cases, and returns a structured note: what happened, what it looked up, what it could not verify, a suggested priority and a suggested next step for a human to take.

Three jobs fit this pattern well:

• Triage: classify, deduplicate and group alerts, then propose a priority with the evidence behind it.
• Enrichment: attach asset, owner, history and reference context to an alert before an analyst opens it.
• Reporting: draft the incident timeline, the shift handover and the periodic summary for management.

None of these require the ability to change anything. That is the point. The team gains time and consistency, and the blast radius of a mistake stays small.

Why start with read-only access?

Read-only is not a timid first step. It is the setup that lets you learn how the agent behaves while the cost of a wrong answer is a wasted minute, not an outage. A wrong summary can be corrected. A wrongly isolated server cannot be un-isolated by an apology.

The principle comes from standard authorization practice: give each identity the least access it needs for its task, and check that access on every request rather than once at setup. The [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) describes this well, including deny-by-default and per-request checks. Apply it to the agent as you would to a contractor: its own identity, its own scoped credentials, no shared analyst logins.

In practice, read-only means:

• A dedicated service identity for the agent, separate from any human account.
• Query access to the alert queue, the asset inventory, the ticketing system and the knowledge base, with no write scope on production systems.
• Write access only to the agent's own workspace: draft notes, draft reports and a log of its actions.
• Credentials that can be revoked in one place without breaking other tools.

A useful test: if the agent's credentials leaked tomorrow, what could someone do with them? With this setup, the answer should be that they could read some data the agent already reads, and nothing more.

How should alert triage work, step by step?

Triage is a good first workflow because it is repetitive, well documented in most teams and easy to check against what analysts decided. Build it as a fixed sequence rather than an open-ended conversation. A predictable sequence is easier to test and easier to audit.

Here is a plan a team can follow for a single alert type, such as suspicious sign-in alerts:

• Step one: define the alert type and write down what a good analyst note contains for it. Include the questions they always ask.
• Step two: list the sources the agent may read for that alert type, and nothing else. Each source gets a scoped, read-only credential.
• Step three: give the agent the team's runbook for that alert type as reference material, not as a script to execute.
• Step four: require a fixed output: summary, evidence list with source for each item, what was not checked, suggested priority, suggested next step for a human.
• Step five: run the agent in shadow mode. It produces notes for past and live alerts, but analysts work as usual and compare afterward.
• Step six: review disagreements weekly. Update the runbook, the sources or the output format, not just the instructions.
• Step seven: let analysts use the note as a starting point, with a one-click way to mark it wrong or incomplete.

The most valuable field is the one about what was not checked. An agent that says it could not reach the asset inventory is far safer than one that fills the gap with a plausible guess.

What enrichment is safe, and what is not?

Enrichment is the agent's quiet strength: attaching the owner of a host, the last change ticket, the previous alerts on the same account and the relevant runbook section. Safe enrichment reads from systems your team already trusts and cites each piece back to its source.

There is one risk you must design for. Alerts carry content written by outsiders: email subjects, user agent strings, file names, web page text. If an agent reads that text and treats it as an instruction, an attacker can steer it. This is prompt injection, and the [OWASP prompt injection prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) lays out the defenses: separate instructions from data, validate outputs, and limit what the model can do even if it is fooled.

The last point matters most for security work. You cannot guarantee that a model will never be misled, so you make sure that being misled has no consequence beyond a bad draft. Read-only access does exactly that.

A short checklist for enrichment:

• Mark all alert content and external lookups as untrusted data in the agent's context.
• Never let the agent follow links or run lookups it constructs from alert text without an allowlist of destinations.
• Strip or flag content that looks like instructions aimed at the agent.
• Require every claim in the note to point to a source the analyst can open.
• Keep sensitive data out of the agent's reach unless the alert type truly needs it, and log each access.

The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) is a good checklist to review with your security architect before go-live, since it names risks like excessive agency and insecure output handling directly.

How do you draft reports people will trust?

Reporting is where the agent saves the most writing time and where trust is easiest to lose. A report that reads smoothly but contains one invented detail teaches readers to distrust all of it.

The fix is to draft from records, not from memory. The agent assembles the incident timeline from ticket entries, alert timestamps and analyst notes, and every sentence maps back to one of those. Where records conflict or are missing, the draft says so plainly rather than smoothing it over.

Useful report types include:

• Shift handover: open alerts, what was tried, what is waiting and on whom.
• Incident report draft: timeline, affected assets, actions taken by humans, open questions.
• Periodic summary for leadership: themes, recurring sources of noise, items awaiting a decision.
• Evidence packs for reviewers, which pair well with the approach in AI for Compliance Teams: Evidence, Reviews and Alerts.

Keep the roles clear. The agent drafts, an analyst edits and signs, and the final report records who approved it. If your organization also supports auditors, the same evidence habits apply as in AI for an Internal Audit Team: Evidence, Samples and Findings.

A report is only as reliable as the weakest sentence a reader cannot trace to a record.

Where should response actions stop?

Response is the tempting extension: if the agent can recognize a compromised account, why not let it disable the account? Because the cost of being wrong is asymmetric. A false positive that locks out a senior executive during a deal, or isolates a production server, is a real incident created by your own tooling.

Treat response as a separate decision with its own gate, not as a feature that arrives with triage. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a helpful reference for structuring that conversation: map the risk, measure it, manage it and assign accountability before the capability exists.

Use this decision guide for any proposed action:

• Is the action reversible in minutes by a person with a documented step? If not, the agent never performs it.
• Is the action on an approved list of narrow actions, such as adding a note, assigning a ticket or requesting information from a user? If not, it stays human.
• Does a named analyst approve each instance before it runs? If not, it stays human.
• Does the action record who approved it, what the agent saw and what changed? If not, do not enable it.
• Has it passed a test set of past alerts, including misleading ones, with no unsafe proposals? If not, keep it in draft form.

Even then, the agent proposes and the analyst executes or confirms. Actions like disabling accounts, isolating hosts, blocking traffic or deleting messages remain human decisions in this model.

Illustrative scenario: a sign-in alert fires for a finance user connecting from an unusual location. The agent reads the sign-in log, finds the user's travel request in the ticketing system, notes two earlier similar alerts closed as benign, and lists a password reset history it could not access. Its note suggests medium priority and recommends the analyst contact the user to confirm. It does not lock the account. The analyst calls, confirms the trip and closes the alert with one line, and the agent's note becomes the case record.

How does Be Human handle this?

Be Human designs, implements and operates personalized AI agents under human control. For a security operations team, a first engagement defines one useful role, such as alert triage for a single alert type, together with the memory and tools it needs, the approval boundaries and an observable success criterion. Access starts read-only, with its own identity and scoped permissions. Managed operations then include monitoring, recurring evaluations against past alerts, integration maintenance, permission review and incident response for the agent itself, with controlled improvements. The service is remote, in English and Portuguese.

How do you know the agent is working?

Decide what success looks like before launch, and make it observable. For triage, that might be whether analysts accept the suggested priority, how often notes are marked incomplete and how long an analyst spends before the first decision. For reporting, it might be how many edits a draft needs before sign-off.

Build a fixed evaluation set from real past alerts, including ones that were tricky, noisy or deliberately misleading, and rerun it whenever you change instructions, sources or models. The [Anthropic guide to evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) is a practical reference for designing that set. Add tracing so you can see which sources the agent read and which steps it took for any given note.

If you also run an internal service desk, the access patterns overlap with AI Agents for IT Helpdesk: Tickets, Access and Runbooks, and the recurring-work habits are covered in AI Agents for Operations Teams: Recurring Work and Reports.

Frequently asked questions

Can an AI agent replace a security analyst? No. The agent handles gathering, comparing and drafting, which frees analysts for judgment, investigation and communication. Decisions, approvals and any change to a system stay with people.

Is it safe to give an agent access to security logs? It can be, if access is read-only, scoped to the sources a specific task needs, tied to its own identity and logged. Treat the content of logs as untrusted, since attackers can place text in them, and make sure a misled agent cannot do anything beyond writing a draft.

Should the agent ever take automated response actions? Only after a separate review, and only for narrow, reversible actions on an approved list with a named human approving each one. Many teams will decide that the agent should never act, and that is a sound choice. The value of triage and reporting does not depend on response powers.

Where should a team start? Pick one alert type with a clear runbook and a steady volume. Run the agent in shadow mode alongside analysts, compare its notes with their decisions, fix the gaps, and only then let analysts use its output as the starting point for real cases.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.