AI Agents for Cybersecurity Firms: Findings and Client Reports

AI agents for cybersecurity companies work best as recall and drafting assistants. They read an analyst's notes, compare them with that client's own findings history, and prepare a report draft for human review. The value depends on keeping each client's records in a separate, permissioned memory, so the agent reuses the firm's method without ever mixing one client's data into another's report.

Key takeaways

• The most reliable first use is drafting: the agent turns analyst notes and prior findings into a report draft, and a named person approves it.
• A findings history lets the agent say whether an issue is new, recurring, regressed or formally accepted by the client.
• Client separation must be enforced in the data stores and tools, not requested in a prompt.
• Evidence from client systems is untrusted input, so the agent treats it as data and never as instructions.
• A good first engagement covers one report type, with named reviewers and a success criterion you can observe.

Where does analyst time go in a security firm?

In penetration testing, managed detection and compliance advisory work, the skilled part is finding an issue and judging what it means. The slower part comes afterward: writing the finding in the firm's format, checking whether the client has seen it before, aligning severity with the firm's rubric, and rewriting the same facts for an executive reader and a technical reader.

That second part is where an agent helps. It does not replace the analyst's judgment about what is exploitable or what matters to a particular business. It takes over the recall and drafting around that judgment, so analysts spend more of an engagement testing and less of it assembling documents.

A useful test for any candidate task: could a careful new colleague do it from the analyst's notes, the client's past reports and the firm's style guide? If yes, an agent can probably draft it. If it needs a judgment about risk to a specific business, the agent prepares the material and the analyst decides.

What does a findings history give an agent?

A findings history is the structured record of everything the firm has reported to one client. For each finding it should hold:

• The title, description and affected asset as originally reported
• The severity given and the reasoning behind it
• The remediation advice and the client's response
• Retest results and current status
• Any risk the client formally accepted, with who accepted it and the stated reason

With that record, the agent can answer questions that otherwise depend on one analyst's memory. Is this new? Did we report it before? Did the client fix it, and did it come back? Did the client decide to live with it? These answers change how a finding should be written, and they are easy to get wrong when a different analyst picks up the account.

Two layers should stay distinct. The firm layer holds method: report templates, the severity rubric, remediation wording standards and style guidance. It contains no client data and can serve every engagement. The client layer holds that client's findings, evidence references, contacts and decisions, and it is reachable only inside that client's workspace. Retrieval from the client layer should return specific records with their source, so a reviewer can trace each statement. Anthropic's guidance on context engineering for agents makes a related point: give the model a small set of relevant, clearly identified information for the task in front of it.

How does report drafting work, step by step?

This is a plan a firm can adopt for one report type before widening the scope.

• The analyst closes the testing phase and attaches notes and evidence references to each finding.
• The agent opens the workspace for that single client and nothing else.
• It compares each finding with the history and labels it new, recurring, regressed, fixed or previously accepted.
• It drafts each write-up in the firm template, using the analyst's notes as the source of truth.
• It lists gaps, such as missing evidence or an unclear affected asset, instead of filling them with guesses.
• It drafts the executive summary and a proposed order for remediation, marked as a proposal.
• It runs consistency checks: severity against the rubric, asset names across sections, terminology against the style guide.
• A named reviewer edits and approves the report, and only a person releases it to the client.
• After approval, the final report and the client's decisions are written back to that client's history.

The gap list matters most. A draft that says what it could not support is more useful to a reviewer than a polished draft that quietly smooths over a hole.

How is client data kept strictly separate?

An instruction in a prompt such as do not mention other clients is not a control. Separation has to be enforced where the data lives and where tools run. A practical checklist:

• One memory store or partition per client, with no shared index across clients
• A session bound to one client at the start, unable to switch clients midway
• Tool credentials scoped to that client's systems, following least privilege and deny by default, as in the OWASP authorization guidance
• The client identifier applied by the tool layer on every retrieval, never supplied by the model
• Output checks that flag names, domains or asset identifiers belonging to any other client
• Logs that record which records were read for each draft
• A defined process to export and delete a client's memory when the relationship ends

Reuse across clients should happen through method, not records. If a remediation paragraph is worth keeping, a person removes the client specifics and promotes it to the firm layer. The agent never learns from one client's file in order to write for another.

The same wall logic appears in AI for Engineering Firms: Proposals, Records and Client Walls, and the memory design for teams serving many accounts is covered in Superintelligence Prep: Managed Service Provider Memory.

What should the agent never do, and what can go wrong?

Security work produces hostile-looking content by nature. Scan output, logs, captured pages, tickets and client documents can contain text that reads like an instruction. OWASP's prompt injection guidance applies directly: keep instructions separate from data, treat everything retrieved as untrusted, and limit what tools the agent can call so a manipulated draft cannot cause harm elsewhere.

Set approval boundaries before the first draft. The agent does not:

• Send anything to a client, since only a named reviewer releases a report
• Change a severity rating without a recorded analyst decision
• Write to the findings record except through the approved write-back step
• Touch client systems or run active tests unless that is the defined role
• Read records from any client other than the one bound to the session

Other failure modes are quieter: overstated severity, a recurring finding described as new, or a remediation step that does not fit the client's environment. Recurring evaluations catch these. Sample finished drafts against reviewer edits, and seed the test workspace with a fictional client whose details must never appear anywhere else. The NIST AI Risk Management Framework is a sensible reference for organizing this as ongoing governance, with clear owners, rather than a one-time launch check.

Teams that deliver reports to many clients from shared operations will recognize the pattern from AI for Call Center Operations: QA, Scripts and Client Reports.

What does this look like in practice?

Illustrative scenario. A small firm performs recurring external assessments for several clients. An analyst finishes one and uploads notes and evidence. The agent opens only that client's workspace and compares the notes with the previous report. It finds that two items are recurring, one was fixed and has returned, and one was accepted by the client with a stated reason. The draft says so in plain language and flags one note that lacks evidence.

The reviewer sees that one item is rated higher than the firm's rubric supports, corrects it and records the reason. The approved report is written back to the client's history. The draft never references another client, and the log shows which records were read. The analyst's time went to testing and review, not to searching old PDFs.

How does Be Human approach this?

Be Human designs, implements and operates personalized AI infrastructure for companies. For a cybersecurity firm, a first engagement defines one useful role, such as drafting assessment reports for one service line, together with the memory and tools it needs, the approval boundaries and an observable success criterion, for example whether reviewers accept the draft structure without rewriting it. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review and incident response, while the firm's people keep control of what the agent can read and release. Service is remote, in English and Portuguese.

To find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent write a client security report without an analyst? No. The agent drafts from the analyst's notes and the client's history, and a named reviewer edits and releases the report. Judgment about exploitability and business risk stays with the people who tested the environment.

Could the agent leak one client's information into another client's report? Not if separation is built into the system. Each client's records sit in their own store, the session is bound to one client, and the tool layer applies the client filter rather than the model. Output checks and logs add a second line of defense, and a seeded fictional client can verify that the wall holds.

What does the agent need before it can start? It needs the firm's report templates, the severity rubric, style guidance and, for each client, past findings in a structured form. Older reports in document form can be converted and checked by an analyst. A small, clean history for one service line is a better start than a large, messy one for everything.

How do we know the drafts are good enough? Define a success criterion up front, such as whether reviewers accept the structure and finding labels without rewriting them. Then review a sample of drafts against the final reports on a recurring schedule, and track which corrections repeat. Repeated corrections point to a template, rubric or retrieval fix.

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