How to Protect Your Organization with AI

Suppose your finance head signs in from a new device at 9:12 a.m. Six minutes later, someone adds an external forwarding rule to her mailbox. Before lunch, a supplier receives a request to change the bank details on an invoice.

The identity system saw the login. The email platform recorded the rule. The finance application has the payment history. Whether anyone connects those facts in time is a separate question.

That is where I would put AI to work.

I have spent over 29 years building enterprise software, across products and organizations with very different budgets and operating constraints. My starting point for security is the business operation: who can move money, who can reach sensitive records, and what would stop the organization from functioning tomorrow morning? Those questions should determine what we ask AI to protect.

Here is how I would approach it.

Begin with a failure you cannot afford

Before choosing a model or buying another security platform, pick a specific loss scenario. For a clinic, it might be losing access to patient records. For a law firm, disclosure of a client's documents. For a distributor, a legitimate payment redirected to an attacker's account.

Trace that scenario through the systems involved. Identify the accounts, permissions, data stores and external services an attacker would need. Then check whether you could reconstruct what happened from the logs you actually retain.

This exercise often produces an awkward discovery: the organization has plenty of alerts but cannot reliably connect an employee to an account, a device and an application session. Resolve those identity mappings first. Check timestamps and missing log sources, too. An AI-generated timeline built from the wrong user or the wrong time zone is worse than an incomplete one that admits its gaps.

Keep funding the basics. Phishing-resistant authentication, prompt patching, restricted administrative access and tested recovery procedures still deserve attention. CISA's guidance on phishing-resistant MFA explains why FIDO/WebAuthn-based authentication provides protection that ordinary codes and approval prompts do not.

Give the investigator a useful first ten minutes

Return to the finance example. This is a hypothetical incident, but it is a useful design test.

I would want the system to assemble a short evidence packet: the sign-in event, device status, recent mailbox changes, relevant payment requests and the account's privileges. Each observation should link to its original record and timestamp. The model can then draft a timeline, suggest plausible explanations and identify the next checks.

It should distinguish three things clearly:

• Observed: an external forwarding rule was created after a sign-in from an unfamiliar device.
• Possible explanation: an attacker may have gained access to the mailbox. A legitimate device replacement remains possible.
• Unanswered: was the forwarding destination approved, and did the account owner make the change?

That distinction makes the output useful to an investigator. A polished paragraph declaring “account compromised” does not.

I would also require the system to report failed queries. If the device platform is unavailable, the report must say so. “No suspicious endpoint activity found” is an unacceptable description of a search that never ran.

The tools serving the model should enforce time windows and result limits. A request to investigate one mailbox should not turn into an unrestricted search across everybody's correspondence. Preserve the original evidence separately; the generated summary is a working aid that may need correcting.

Start with recommendations. An analyst reviews the evidence and chooses the response. Later, a narrowly defined playbook might automatically collect additional records or open a case. Suspending an executive's account or isolating a production server requires a different level of confidence and authority.

Use AI to shorten the vulnerability queue intelligently

A scanner can produce a long list of vulnerabilities. Someone still has to decide what gets fixed before Friday.

I would use AI to help assemble the context around each finding: whether the affected version is really deployed, whether the service is reachable, what identity it runs under, which business process depends on it, and who owns the fix. The useful output is a ticket an engineer can act on, with supporting evidence and a proposed verification step.

Known exploitation deserves particular attention. CISA maintains its Known Exploited Vulnerabilities catalog to help organizations identify vulnerabilities with evidence of exploitation in the wild. Combine that signal with your own exposure and business impact. Absence from the catalog is not evidence that a vulnerability is safe.

For example, an exposed service with an actively exploited flaw and access to customer records deserves an urgent review. A similarly scored finding on an isolated test machine may need a different schedule. The model can explain that distinction, but the inventory and exposure evidence must support it.

Do the exact matching in code where possible. Retrieve current advisories from trusted sources. Do not ask a language model to recall which software versions are affected, or allow it to invent a compensating control because a ticket needs an answer.

Put fraud checks inside the transaction

An email classifier is one place to use AI. The payment workflow is another, and sometimes the more valuable one.

Consider a request to change a supplier's bank account. A model can help extract the request from an email thread and flag unusual urgency or departures from earlier correspondence. Software can compare the proposed details with the supplier record and check whether the required approvals exist.

The payment system should still enforce independent verification through a known contact channel. A convincing email, a familiar voice or an AI verdict of “likely legitimate” should not remove that requirement.

This is where application architecture matters. If bank details can be changed through an API without the verification required by the user interface, the control is incomplete. Enforce the rule at the service handling the change, and record who approved it. AI can bring a suspicious request to attention; the transaction boundary must enforce the decision.

The same approach applies to changes in payroll details, privileged access requests and unusual exports of customer data. Choose a workflow where an extra piece of context could change the outcome.

The security assistant needs boundaries of its own

A security assistant reads material supplied by potential attackers: emails, attachments, web pages and even text embedded in logs. Some of that material may contain instructions intended to manipulate the assistant.

OWASP describes this as indirect prompt injection. Retrieving documents or fine-tuning a model does not eliminate it. A system prompt telling the assistant to ignore malicious instructions is insufficient protection for a tool that can change production systems.

My default design separates investigation from execution. The investigator gets scoped, read-only tools. A separate service handles response actions, checking the requesting identity, target, allowed operation and required approval in ordinary application code. The model cannot grant itself additional permissions.

Make the response request specific. “Revoke this user's sessions for this incident” is reviewable. “Run whatever command is necessary to contain the threat” is far too broad. Bind any approval to the exact action and target, expire it, and reject changes after approval. Check that the incident state still permits the action when it executes.

For reversible actions, document and test the reversal. For actions that destroy data or interrupt a critical service, require stronger review. A stop control should disable the assistant's ability to act while keeping ordinary monitoring and incident response available.

Decide where the evidence may go

Security telemetry can contain access tokens, customer details, internal addresses and confidential correspondence. Sending it to a model is a data-access decision.

Select the fields needed for the investigation, remove secrets where possible, and apply access controls before retrieval. Check the model service's retention, training-use and administrative-access terms against the data you intend to send. “Enterprise” in the product name is not an answer to those questions.

A locally hosted model may suit some sensitive workloads, but it brings operational responsibilities: patching the serving software, protecting model files, restricting network access and controlling diagnostic logs. Hosting location alone does not establish security.

Remember the generated case report as well. It may bring together sensitive facts that were previously scattered across several systems. Restrict its audience, retention and exports accordingly. NCSC's secure AI development guidance covers security across design, development, deployment and ongoing operation; those responsibilities continue after the pilot works.

Measure the mistakes as carefully as the time saved

For a first pilot, I would choose one investigation workflow and run it alongside the existing process. Give analysts the normal tools, compare outcomes, and record when the AI helped or made the work harder.

Measure time to a supported decision, incorrect escalations, missed incidents in a labelled evaluation set, unsupported statements and analyst rework. Track business disruption separately. Faster containment has limited value if the system repeatedly locks legitimate employees out of critical work.

A model's confidence score needs validation against observed outcomes before it can inform an action threshold. It should never be the only condition for a disruptive response.

Build the evaluation set from sanitized historical cases and controlled exercises. Include ordinary events that resemble attacks: travel, replacement devices, approved bulk exports and emergency maintenance. Include incomplete evidence and conflicting timestamps. Keep some cases out of tuning so the final check measures more than familiarity with examples.

Also test an unavailable model, a broken log connector and an instruction hidden in an email. An outage should leave the team with a clear fallback, not silently close its investigations. Repeat the relevant evaluations when you change the model, prompt, tools or data sources.

What I would do in the first month

In the first week, select one loss scenario, name its owner and map the evidence needed to investigate it. Record how long the current process takes and where analysts lose time.

In the second week, build the smallest useful read-only integration. Require source references and explicit missing-data notices. Review exactly what leaves each system and what gets retained.

Spend the third week replaying cases with the people who would use the system. Ask them to challenge its conclusions. Pay particular attention to occasions when a confident summary makes them less likely to inspect the evidence.

In the fourth week, decide whether the results justify a limited rollout. If they do, introduce one bounded action at a time, with an owner, an approval rule and a tested recovery procedure. If they do not, fix the data or narrow the task before buying more capability.

That is the approach I would bring to an AI security review: follow the business risk through the software, examine the evidence, and make every permission earn its place. A useful review should leave the engineering team with specific changes it can implement and the business owner with a clear account of what remains exposed.

If you are considering AI for your security operations, connect with me on LinkedIn. Bring one workflow your team struggles to investigate or control. That is a good place to start.