AI Security Operations: An Enterprise Whitepaper

Security operations teams are being asked to solve two AI problems simultaneously. The first is the one they wanted: alert volumes exceed clearance capacity by wide margins, investigation is slow because context gathering is manual, and AI can help with both. The second arrived uninvited: the organisation is deploying AI systems that hold credentials, act on instructions from untrusted content, and read data across permission boundaries, and no existing control set anticipated that. This whitepaper covers both. It draws on FISTA Solutions' security practice across AI agents deployments and complements ai security operations center and the AI agent security architecture whitepaper.

Part one: AI in the SOC

Where does triage support deliver?

In the gap between alert volume and analyst capacity, which in most SOCs is the defining constraint. Analysts spend the majority of their alert-handling time gathering context: who is this user, is this host normal for them, has this indicator appeared before, what else happened around this time, is there an open ticket that explains it.

Triage support assembles that context automatically, ranks alerts by likelihood and potential impact, groups related alerts into a single incident rather than presenting them individually, and drafts the initial assessment. The analyst arrives at a decision rather than at a research task.

The measures are alerts per analyst per shift, time to first assessment, and escalation accuracy. The measure that matters most is dwell time on genuine incidents, since the point of clearing noise is finding the real thing faster.

What does investigation support add?

Timeline assembly across sources, which is the slowest part of most investigations. Given an initial indicator, the system gathers related authentication events, process execution, network connections, file activity, and email, correlates them into a chronology, and highlights the deviations from normal patterns.

It also supports the hypothesis work: what else did this identity touch, what does this binary normally do, has this pattern appeared elsewhere in the estate. Analysts retain the judgement about what the evidence means, which is the part that determines whether an investigation reaches the right conclusion.

How does detection engineering change?

Coverage assessment becomes tractable. Mapping existing detections against a threat framework, identifying gaps, and assessing whether a rule would actually fire on a given technique are all tedious manual tasks that get deferred.

AI contributes gap analysis against frameworks, rule quality assessment including detection of rules that have never fired or that fire constantly, translation of detections between platforms during migrations, and drafting of new rules from threat intelligence. Validation stays human, because a rule that looks correct and does not fire is worse than no rule.

What response should be automated?

Reversible actions with tested playbooks and clear triggering conditions: isolating a host, disabling an account, blocking an indicator, rotating credentials, quarantining email. Each with logging, an approval gate where business-critical systems are involved, and a tested rollback.

What should not be automated: anything irreversible, anything affecting production systems where the business impact of a false positive exceeds the security benefit, and anything requiring judgement about whether unusual activity is authorised. The asymmetry matters because an automated response to a false positive during business hours can cause more disruption than the incident it was preventing.

Part two: securing AI systems

What is the new attack surface?

Surface	Attack	Primary control
Agent tool access	Induce unauthorised actions	Least-privilege scoping
Retrieved content	Indirect prompt injection	Permissions plus approval gates
User input	Direct injection, jailbreaking	Output validation, guardrails
Retrieval corpus	Poisoning to corrupt answers	Content provenance and review
Agent memory	Persistent poisoning	Write criteria and review
Model supply chain	Tampered weights, malicious dependencies	Provenance and integrity checks
Agent credentials	Theft or misuse	Short-lived, scoped, attributable
Egress paths	Exfiltration through agent actions	Egress control and monitoring
Cost	Denial through expensive loops	Rate and cost caps

The row that changes security thinking most is the second. Indirect prompt injection means anyone who can place content where an agent reads it, a ticket, an email, a document, a web page, can attempt to direct that agent, and the agent's permissions become theirs. That is a privilege escalation path that no conventional control catalogue describes.

Why is containment more important than detection?

Because detection of prompt injection is unreliable by nature. The attack is expressed in natural language with unbounded variation, and a classifier trained on known patterns is bypassed by rephrasing. Detection reduces volume; it does not close the path.

Containment does. If an agent can only read the tickets the requesting user can read, can only call three tools, cannot send data outside a defined boundary, requires approval above a value threshold, and has every action logged and attributable, then a successful injection achieves something bounded and visible rather than something arbitrary.

The design question for every agent is therefore: what is the worst outcome achievable within its permissions, and is that acceptable? See how to design tool permissions for ai agents.

What does the SOC need to monitor in an AI estate?

Agent identities as actors, which requires the agents to have identities in the first place. The detections that matter: agent tool use outside its normal pattern; retrieval of documents outside a user's typical entitlement scope; action volumes deviating from baseline, which catches loops and abuse; egress to unexpected destinations; agent credential use outside expected hours or from unexpected sources; and repeated guardrail or validation failures, which frequently indicate probing.

This requires telemetry from the AI platform into the SIEM, which is a platform design requirement rather than a security afterthought. Agent estates built without it are invisible to the SOC, which discovers them during an incident.

How does the SOC assess AI systems before deployment?

Through the existing secure development and third-party risk processes, extended with AI-specific questions: what data the system reads and whether retrieval respects entitlements; what actions it can take and what the blast radius is; where untrusted content enters; what validation applies to outputs; how it is logged and whether that reaches the SIEM; what the kill path is; and how model and prompt changes are controlled.

Red teaming before launch is the practical test of the answers. See the AI red teaming program whitepaper.

What about shadow AI?

The largest practical exposure in most organisations. Employees use consumer AI tools with company data because the tools are useful and the sanctioned alternative is either absent or worse.

Enforcement alone fails, as it has with every previous category of shadow IT. The effective response pairs discovery, through network and SaaS monitoring, with a genuinely usable sanctioned option, so the compliant path is the easy one. Policy without provision produces invisible usage rather than no usage. See what is shadow ai.

How do the two halves connect?

Through the same platform discipline. The AI the SOC uses and the AI the organisation deploys both need identity, logging, evaluation, permissions, and kill paths, and building those once serves both. Security teams that build their own AI tooling outside the organisation's platform create exactly the ungoverned estate they warn others about.

What is the sequence?

1. Inventory AI systems with permissions, data access, and untrusted input paths.
2. Get telemetry into the SIEM from the AI platform before adding detections.
3. Tighten permissions on the highest-blast-radius agents.
4. Deploy triage support in the SOC, measured against analyst capacity.
5. Add AI-specific detections for agent and retrieval anomalies.
6. Red team the highest-risk systems and convert findings into regression tests.
7. Address shadow AI with discovery plus a usable sanctioned option.

What goes wrong?

Automating response before playbooks are tested. Treating prompt injection as a detection problem. Agents with shared credentials, so nothing is attributable. AI platform telemetry that never reaches the SOC. Security review applied to the public chatbot while internal agents hold write access to finance systems. And shadow AI policies with no sanctioned alternative.

How does this change the security team's structure?

Two roles appear that most SOCs did not have. The first is detection engineering for AI systems, which requires understanding how agents work well enough to know what anomalous looks like. An analyst who has never seen an agent trace cannot write a useful detection for agent misuse, so this role usually grows from someone embedded with the AI platform team rather than from the existing detection function.

The second is AI security assurance, sitting in the review path for new AI systems and running or commissioning red team exercises. This is closer to application security than to operations, and the same people often cover both.

What does not change is accountability. AI systems belong in the same risk register, the same vulnerability management process, and the same incident response as everything else. Security functions that create a parallel AI track find it is under-resourced and bypassed when a real incident arrives.

What should be reported to the board?

The AI estate's exposure in terms a board can act on: how many AI systems are deployed, how many can take consequential actions, what the largest blast radius is and whether it is acceptable, whether the estate is visible to the SOC, and what red teaming has found and whether it was fixed.

The question boards increasingly ask, and that most security functions cannot yet answer, is simple: if an attacker put instructions into a document our agents read, what could they cause to happen? Having a specific, evidenced answer is the outcome this whitepaper is aimed at.

How FISTA Solutions delivers this

FISTA Solutions builds AI systems with security controls designed in, least-privilege agent permissions, entitlement-filtered retrieval, output validation, egress control, and telemetry that reaches the SOC, and builds the triage and investigation tooling security teams need, through AI enablement, AI agents, and forward deployed engineers working with security teams. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To use AI in the SOC and secure the AI you deploy, message FISTA on WhatsApp, or read the AI agent security architecture whitepaper.