What an Agentic SOC Teaches Us About Enterprise AI

Nearly every conversation returned to the same operating questions: what agents should do, where people must stay involved, what evidence needs to be preserved, and who owns the outcome when an AI-assisted decision is wrong.

Security makes those questions unusually visible because mistakes can have immediate consequences. A poorly designed security agent might overlook an attack, block legitimate activity, expose sensitive data, or disrupt a critical system, but the underlying requirements are not unique to security.

Enterprise AI is not primarily a model-selection problem. It is a process, architecture, governance, and accountability problem.

Matthew Morrow (opens in a new tab), CTO at Rockhaven Homes, repeatedly returned to this point during the discussion: understand and fix the process before trying to automate it. That resonated because process is where organizations often struggle first.

Organizations may know they want to use AI before they can clearly describe how the work gets done today. The documented process explains part of it. Experienced employees carry the rest as tribal knowledge. Exceptions accumulate, informal handoffs become normal, and decisions happen because someone knows whom to call rather than because ownership is clear.

The better question is not, "Where can we insert an agent?" It is, "If we were designing this process today, which parts should be performed by people, conventional software, workflow automation, analytics, and AI?"

The objective is not to automate the existing process exactly as it operates today. The objective is to create a better process.

Amanda Cameron-Windsor (opens in a new tab), Global Retail Field CTO at Snowflake, made a point that sharpened the theme: agentic AI tends to amplify the operating model it inherits.

When responsibilities are clear, data is reliable, decision criteria are explicit, and governance works, agents can accelerate the work and increase capacity. When those foundations are weak, AI accelerates the weakness.

• Unclear ownership remains unclear.
• Bad data moves faster.
• Inconsistent decisions become automated inconsistencies.
• Poor handoffs create larger operational gaps.

That is a stronger warning than simply saying organizations should fix bad processes before implementing AI. AI can amplify organizational ambiguity just as readily as it amplifies productivity.

The Agentic SOC presented at the forum used multiple specialized agents rather than one general-purpose AI. Paul Moskovich (opens in a new tab), Co-Founder and CEO of Cyngular Security (opens in a new tab), demonstrated a system in which agents supported specialized parts of the security workflow, including observation, threat hunting, investigation, evidence assembly, recommendations, and reporting.

The specific security functions matter less to me than the architectural pattern. Enterprise agentic systems will often need specialized capabilities for gathering information, monitoring events, analyzing evidence, identifying anomalies, recommending actions, validating outcomes, and documenting what happened.

That resembles the way organizations already structure human work. Different participants have specialized responsibilities, but something must coordinate the whole. For agents, that orchestration layer has to determine who does what, what context and tools each agent receives, how work is sequenced, what happens when agents disagree, when a person must become involved, and how the chain of activity is recorded.

Amanda raised another dimension of the same problem: enterprise orchestration will have to work across technology ecosystems rather than inside a single clean environment. Without that coordination, organizations risk replacing disconnected tools with disconnected agents.

Paul's demonstration made the question of autonomy concrete. The resolver was described as effectively read-only in the customer environment. It could investigate an incident, assemble evidence, recommend remediation, and generate the commands needed to act extremely rapidly, but it stopped short of executing those commands. People retain that authority.

Capability and permission are not the same thing.

An agent that can perform an action is not necessarily an agent that should be authorized to perform it. Instead of treating autonomy as a choice between human control and fully independent agents, organizations can treat it as a progression.

1. 01

   Observe

   Gather context without changing the environment.

2. 02

   Recommend

   Analyze evidence and propose the next action.

3. 03

   Execute with approval

   Prepare the action while a person retains authorization.

4. 04

   Execute bounded actions

   Perform low-risk, reversible actions inside defined limits.

5. 05

   Operate in a controlled domain

   Handle a narrow class of work with monitoring, escalation, and audit controls.

The appropriate level depends on consequence, data quality, reversibility, whether the situation is routine or unusual, and how reliably the agent has performed. The Cyngular example is useful precisely because the technology could go further than the permission it had been given.

Agents can reduce the time people spend collecting information, switching between systems, building timelines, preparing reports, and performing repetitive analysis. That does not eliminate the human role. It changes it.

One phrase from the evening described it as moving people from data miners to commanders. I think that distinction is useful. People spend less time mechanically producing information and more time setting objectives, defining constraints, evaluating evidence, handling exceptions, making consequential decisions, and improving the process itself.

That also changes what AI literacy means. Organizations often describe AI literacy as knowing how to write prompts or use an assistant. Those skills matter, but operational AI literacy is broader. Employees need to understand the work well enough to make tacit knowledge explicit, define success and failure, supervise automated work, and recognize when an agent is confidently wrong.

Tyler Mullins (opens in a new tab) made a comment that immediately caught my attention: AI does not really think in the human sense. It predicts outputs from the information and patterns available to it.

Whatever terminology we use to describe model reasoning, the practical implication is more important than the philosophical debate. The AI cannot be held accountable. Organizations do not get to say, "That is what the AI decided."

Accountability cannot be delegated to the model.

People choose the system. People provide the data. People define the process and controls. People grant access. People decide how much autonomy the agent receives. That does not mean every AI-assisted action requires manual approval. It means every system participating in consequential work needs an identifiable human or organizational owner.

If an agent participates in consequential work, knowing the final output is not enough. The organization needs to reconstruct what happened: what triggered the agent, what information it accessed, which policies and instructions applied, what tools it used, what it recommended or attempted, where a person intervened, what action was ultimately taken, and what happened next.

That record supports compliance, but compliance is only part of the value. The same trail supports troubleshooting, performance improvement, incident investigation, employee trust, risk management, and organizational learning.

It can also capture institutional knowledge. When experienced operators review recommendations, handle exceptions, and explain why one action is better than another, those decisions can improve future playbooks and operating procedures.

AI governance is often treated as an IT responsibility. It is not. Technical teams may implement controls, but the people accountable for the underlying business process have to participate in deciding what an agent may do, what it may never do, who supervises it, and how its decisions are reviewed.

Ann Dunkin (opens in a new tab) moderated the first panel and repeatedly brought the discussion back to practical questions of autonomy, trust, governance, and what organizations should actually do next.

Those questions cannot be answered only in an enterprise-wide AI policy. An agent helping draft an internal communication does not present the same risk as an agent changing financial records, blocking network traffic, modifying production code, or communicating directly with customers. Governance has to reflect the actual context and consequence of the work.

Organizations do not need to begin with autonomous agents making consequential decisions. In fact, they probably definitely should not. A good first implementation is frequent enough to produce meaningful learning, narrow enough to understand, low-risk enough to experiment safely, supported by accessible data, and valuable enough that employees care whether it succeeds.

Start with the people who perform the work today. Ask where they spend their time, what information they repeatedly gather, which decisions are routine, where handoffs fail, what mistakes keep happening, and what evidence would make them trust an AI recommendation.

Ask one question that may be even more revealing: what would you never allow this system to do on its own?

The answer helps define the boundary between capability and acceptable autonomy. Then redesign the process before selecting the technology.

That was my biggest takeaway from an evening focused on the future of the security operations center. I went expecting to learn about AI in security. I left thinking about something larger: security may be giving us an early look at what it takes to put AI to work across an enterprise.

The specific agents will vary by industry and function. The requirements for making them useful, trustworthy, and accountable will not.