Beyond the Chatbot: Delivering an Agentic SOC for Real-World Defense

Beyond the Chatbot: Delivering an Agentic SOC for Real-World Defense

Speakers: Peter Smith (Director, Agentic SOC Product Management, Salesforce); Ravi Kiran Sharma "RK" (Lead Security Engineer, Salesforce)

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 4, 2026, San Francisco

Reading time: ~9 minutes

Note: No YouTube recording is available for this session.

TL;DR

Salesforce built an Agentic SOC — a network of specialized AI agents operating in Slack alongside human analysts — that takes a threat intelligence report and completes the full cycle from alert to threat hunting to containment to detection deployment in under ten minutes. The architecture rests on eight core primitives, an "AI constitution" governance framework, and a philosophy of treating agents as digital teammates rather than automation scripts.

Introduction

Kevin Mandia once described his dream as a smartphone app that could go from alert to containment in ten minutes. Pete Smith opened his [un]prompted talk by declaring that Salesforce's Security Operations Center had met and exceeded that expectation.

Smith, who leads Agentic SOC product management at Salesforce, and his co-presenter RK Sharma, the lead security engineer behind the system, walked through a live demonstration of what they've built: a multi-agent system operating in Slack that can ingest a threat intelligence report, identify indicators of compromise, hunt across Salesforce's enterprise environment, propose and execute remediation actions, and page an incident commander — all within a ten-minute window, with human approval gates at every high-risk decision point.

This is not a proof of concept. The system runs on Salesforce's actual security infrastructure, built on top of existing SOAR tooling and existing systems of record, with no infrastructure replacement required.

What an Agentic SOC Actually Looks Like

The Salesforce Agentic SOC is defined by its conversational interface. Agents live in Slack channels alongside human analysts. The interaction model is collaborative: agents propose, humans approve, agents execute. When an analyst has a question, they ask it in natural language. When an agent encounters ambiguity that requires human judgment, it surfaces that ambiguity explicitly rather than guessing.

Smith introduced the concept of the Digital Teammate Test — a reframing of the Turing Test for security operations. The Turing Test asks whether a machine can fool a human into thinking it's human. The Digital Teammate Test asks something different: "Can this agent empower a human to trust it as a peer?"

The failure condition is instructive: if the analyst feels like they are "using software," the agent fails. The pass condition: if the analyst feels like they are "collaborating with a junior analyst," the agent passes. The practical difference shows up in ambiguous scenarios. A failing agent loops indefinitely, stops silently, or takes inappropriate autonomous action. A passing agent surfaces the ambiguity: "I've tracked this lateral movement to Server B, but the command used is ambiguous. It resembles an admin script but the timing is suspicious. I need a human eye on this specific command line before I block it."

The Demo: Venomous Bear, Start to Finish

The centerpiece of the talk was a four-minute demonstration narrated in real time. The scenario: Smith and RK were in a meeting with CrowdStrike when they learned about a nation-state actor called Venomous Bear. RK opened Slack and queried their agent — called Kestrel — with the CrowdStrike report number (2026035, a real report containing roughly eight IOCs including domains and MD5 hashes).

The agent pipeline that executed from that single message:

1. Normalizer agent. Recognized the seven-digit CrowdStrike report format without being explicitly told what kind of report it was, fetched it, and extracted all IOCs. A Salesforce hunt record was created automatically, capturing metadata including who launched the hunt and when.

2. Hunt planning agent. Examined the IOCs and report context, then proposed a hunting plan — a hypothesis about what data sources to search and how. The plan was shown to RK in Slack, who was asked for approval and a business justification. That justification is stored both to inform future agent memory and as a regulatory audit trail.

3. IOC investigation agent. With the plan approved and locked as read-only, a dedicated IOC investigation agent executed the hunt across the SIEM and threat intelligence systems. This agent is deterministic: given tools, data sources, and an IOC, it executes and returns findings without reasoning about what to do next.

4. Findings review agent. Evaluated the hunt results, determined that IOCs were found in the environment (a demo environment, not production), and packaged a report into the Salesforce hunt object.

5. Hunt concluder agent. Synthesized the findings for the human and proposed three recommended next steps: deploy updated detection rules, block IOCs and contain affected endpoints through CrowdStrike, and page an incident commander.

Each of these proposed actions is a non-read-only operation with real enterprise consequences, so each required explicit human approval with documented justification. RK approved the plan conversationally — and could have said "I don't like this plan, do this instead" to trigger a new planning cycle.

Three specialist agents then executed in parallel: a threat detection engineer agent wrote new detection rules based on the IOCs; a remediation execution agent handled endpoint containment through CrowdStrike; and an incident communication agent spun up a dedicated Slack channel, paged the incident commander, and added all relevant agents and humans.

Total elapsed time: under ten minutes, from the first Slack message to containment confirmed.

The Architecture: Eight Primitives and an AI Constitution

Smith described the architecture as deliberately pragmatic. The system was not built from scratch — it was built on top of Salesforce's existing SOAR platform (with 257 Python integrations) and existing systems of record, with an intelligent agentic reasoning layer added on top. "If any vendor tells you that you have to re-envision your infrastructure to build an Agentic SOC, that's not true."

The architecture uses neither MCP nor A2A protocols. "You can build agentic software without MCP, without A2A." The team built direct integrations where needed.

Before writing a line of code, the team developed an AI Constitution — a governance document that codifies the rules for how the Agentic SOC operates. The constitution's first article defines eight core primitives that every agent in the system must implement:

• Blocks one and four: Cognitive layer — reasoning, planning, and goal management
• Blocks two and three: Execution and orchestration — tool use and agent-to-agent handoffs
• Blocks five and six: Safety guardrails — ensuring agents don't break production
• Blocks seven and eight: Engineering design and best practices

Each agent is defined by an agent card: a configuration document specifying the agent's persona, objective, allowed tools, model parameters (temperature, max tokens, max iterations, PII masking), and what other agents are permitted to invoke it. This card-based design prevents scope creep and context drift — each agent is mapped to exactly the workload it should handle.

The concept of max iterations deserves special mention. An iteration is not a single LLM call; it is a full execution cycle — receive input, reason, plan, execute multiple tools, return output. Every agent has a hard maximum. If it hits that limit without completing its objective, the governance layer exits the session gracefully, saves state, and hands off to the next layer.

Tool configurations abstract API calls entirely from the LLM, ensuring API keys and credentials are never exposed to the base model. Permissions are enforced at both ends: the agent card specifies what tools an agent can call, and the tool config specifies what agents are permitted to call that tool.

Lessons for Teams Building Their Own Agentic SOC

Smith closed with a set of principles extracted directly from the team's experience building and running the system:

Use deterministic orchestration for high-risk workflows. Open-ended autonomous chains are appropriate for exploratory tasks like threat hunting. For high-risk actions — containment, detection deployment — deterministic orchestration keeps LLM reasoning within defined rails.

Build many small, focused agents, not monolithic ones. The demo showed nine agents. The agent card registry has 600 lines. Each agent does one thing. "They should be numerous, focused, and specialized to what they do."

Always have humans in the loop — especially while training these systems. The teammate model means agents work with people, proposing before acting. "Ask mode and plan mode — every IDE has this; your agents should too."

Use your existing infrastructure. The Salesforce Agentic SOC did not replace their SOAR. It taught agents to speak to it. Now agents can do everything the SOAR could do, but with reasoning and judgment rather than hardcoded workflows.

Let agents earn trust. Trust is built incrementally through demonstrated performance on low-stakes workflows before expanding to autonomous action on high-stakes ones.

On engineering costs, Smith offered candid transparency: the entire system configuration was written by Claude. "I didn't write a single piece of code myself" — though he emphasized that foundational Python knowledge was necessary to understand what was being built and review outputs.

Key Takeaways

• Alert to containment in under ten minutes is achievable today using a coordinated chain of specialized agents with human approval gates at every high-risk decision point.
• The Digital Teammate Test is a better success metric than the Turing Test. Build agents that surface their uncertainty and ask for help; penalize agents that loop silently or take autonomous action when human judgment is needed.
• Start with an AI Constitution and eight primitives. Governance-first architecture prevents the scope creep and context drift that destabilizes monolithic agent designs.
• Never replace existing security infrastructure to build an Agentic SOC. Layer intelligent reasoning over existing SOAR, SIEM, and threat intel tooling — the integrations you already have are an asset.
• Agent cards enforce specialization and prevent privilege creep. Each agent should have a defined persona, bounded tool access, and a hard iteration limit — configurations that make behavior predictable and auditable.

Slides Reference

Slides available: Beyond the Chatbot: Delivering an Agentic SOC for Real-World Defense (Salesforce). Key topics include: Security Operations in the Agentic Enterprise, the AI Constitution framework, Foundational Elements of an Agentic SOC (eight primitives), the Digital Teammate Test (pass/fail criteria and scenario walkthrough), and a live agent demo overview.