If a critical application’s response time is slow, IT operations teams have to determine whether it is a network issue, a server issue, or a cyber attack. That decision gets harder when the suspicious activity crosses identities, cloud infrastructure, and applications. And the business needs a coordinated response while the troubleshooting/investigation is still unfolding.
My view is that the modern Security Operations Center (SOC) needs a clearer division of responsibilities. AI-powered analysts should get involved with the IT operations team to take a deeper dive for repeatable evidence gathering and enrichment, when evidence leads to suspicious activity. People should concentrate on the decisions that require experience and carry business risk. At Gruve, we are building toward this model in our AI SOC work, particularly for neoclouds providing GPU and AI infrastructure services.
What the machine needs to assemble before a person opens the case
By the time an analyst opens a case, related events should be assembled into a timeline, relevant identities identified, and affected assets listed. AI can retrieve evidence, consult approved runbooks, and suggest the next investigation step. Triage still requires judgment. Conflicting signals and missing context have to stay visible, with source evidence supporting every recommendation.
Observability supplies the context
Logs record events, metrics show changes in performance, and traces follow requests across applications and services. Combined with security telemetry and application dependencies, they help teams connect suspicious activity to the business service at risk. What makes the connection between suspicious activity and business risk is data such as shared timestamps, asset identifiers, and ownership records.
Splunk can serve as the shared investigation environment. Runtime visibility adds another layer. The Isovalent application ecosystem observes process execution, system calls, and network and file activity with Kubernetes context. That exposes workload behavior a perimeter firewall alone cannot see. The value comes from connecting these signals to identity and application activity.
Here is some data sources that are important to derive insights into AI consumption and activities: track model requests, token usage, and spending by identity, workload, model, and region. Unexpected growth can indicate stolen credentials or unauthorized model use, and it can also reflect legitimate demand, a misconfigured application, or a cyber-attack. In one documented LLMjacking campaign, a compromised cloud identity was used to unlock foundation model services across several models and regions, generating nearly 200,000 requests in two minutes before throttling caught it (CrowdStrike, 2026). Consumption is an important investigation signal. Correlate it with permissions and traffic before deciding what it means.
Consider an illustrative incident at an AI infrastructure provider. Model usage rises sharply, customers experience delays, and a service identity begins accessing an unfamiliar region. An AI analyst assembles the timeline, checks approved workloads and recent changes, and identifies the affected tenants. The human analyst then has the evidence to distinguish an authorized workload from misuse.
The approval workflow has to be defined and tested first
Security orchestration, automation, and response (SOAR) playbooks can gather evidence and execute approved actions within established limits. Teams should agree in advance which actions may run automatically, which require approval, and how to stop or reverse them. Change governance should authorize those boundaries before an incident, not during one.
Start with tightly scoped permissions, model and region allowlists where supported, and appropriate usage quotas. A confirmed compromise might trigger a tested session-revocation or workload-isolation workflow. Actions affecting critical services need safeguards that reflect customer impact. Accidentally interrupting a customer’s purchase or inference workload has business consequences.
What the people do
Human analysts assess ambiguous findings and approve containment beyond the agreed automation boundaries. They work with business, legal, and communications leaders on escalation and disclosure decisions. They also review AI-closed cases, investigate missed threats, and provide recommendations to improve early detections.
The AI analysts need operational oversight
Assign a responsible owner and a defined review schedule. Record who enabled each AI agent, which tools and permissions it used, what it changed, and whether it completed its assigned work. Investigate failures and unexpected activity. An owner’s name in an inventory has value only when somebody actively reviews the agent’s behavior.
Manage agents through onboarding, operation, and retirement. Give each AI agent appropriate access to its task, review that access when its role changes, and revoke credentials when it is retired. When a new version is deployed, verify that the old instance has stopped. As a precaution, treat logs, tickets, and repository content as untrusted input so embedded instructions cannot authorize additional actions.
Segmentation, repositories, and pipelines
Segmentation limits the damage if an agent or identity is compromised. For example, Cisco ISE and TrustSec use security group tags and policy enforcement to restrict permitted network communication. A tag alone does not provide protection. The policy and enforcement coverage have to be configured correctly. Network segmentation also needs application permissions and workload controls to constrain what an agent can do after it connects.
Source repositories and delivery pipelines need their own safeguards. For example, GitHub’s security guidance addresses untrusted workflow inputs, token permissions, and secret protection. For coding agents, apply those controls alongside isolated execution and approval for sensitive changes. Network segmentation cannot replace authorization inside a repository or a deployment workflow.
Where to start
I would begin with one investigation workflow. Then, measure accuracy, analyst effort, missed threats, and time to verify containment and recovery. Review customer disruption and operating costs alongside recovery speed. Expand automation only when the evidence supports greater authority. That is how a SOC increases its capacity while keeping people accountable for the decisions that matter.
Look at what your analysts spent last week doing. How much time went into assembling evidence, and how much into deciding what policies to enforce and what the business should do?
Learn more about Gruve’s AI SOC.
Check all thoughts
