The Agentic SOC Is Coming, But Who Governs the Agents?

CrowdStrike published "The Agentic SOC Guide." Microsoft embeds Copilot Security agents into its cloud security stack. Palo Alto integrates AI assistants deep into XSIAM.

The agents deployed inside the SOC to secure the infrastructure have the same governance gaps as any agent deployed outside it.

What the vendors are building

An agentic SOC is, at its core, a set of autonomous AI agents given access to the security infrastructure itself. These agents operate against SIEM queries, can manipulate firewall rules, isolate endpoints, modify ticketing systems, and trigger response playbooks. They're designed to reduce human toil and accelerate mean time to response.

It is being sold on speed: an agent triages continuously and does not queue behind a shift change.

An agent inside the SOC holds the SOC's credentials, which are the most sensitive in the building. A compromise of that agent is not a chatbot being tricked into leaking a prompt. It's an attacker inside your security operations center, running with the agent's credentials, querying your SIEM, modifying your firewall rules, and isolating your infrastructure.

The governance gap

An agentic SOC agent operates under the same threat model that any agent does. Who validates what the agent is trying to do before it does it? What policy prevents it from making a mistake? How do you enforce that policy at the tool-call level, not the prompt level?

This maps to three categories of risk:

• T2 tool misuse: The agent has legitimate access to a tool but uses it in an unauthorized way. An agent with firewall rule read access decides to enumerate all rules to find ones matching a pattern, then modifies ten rules to block internal traffic. The agent thought it was responding to an incident. It wasn't. No policy enforced the boundaries.
• T3 privilege compromise: The agent's credential is stolen or the agent process is compromised. An attacker runs the agent's API key against the SOC infrastructure directly. Without governance, there's no moment of enforcement: the attacker just exercises the agent's existing permissions.
• T9 identity spoofing: An agent claims to be a different agent, or a human claims to be an agent. Without strong audit trails showing which agent made which decision, forensics become impossible.

Five questions CISOs should ask

If your vendor is pitching an agentic SOC (or if your team is building one internally), ask these five questions before deployment:

1. What actions can the agent take autonomously?

This seems obvious. It isn't. The answer is usually the agent's role, or the security policy. Governance is narrower than that: if the agent can isolate an endpoint, can you stop it isolating your primary backup server, or does it either hold that permission or not?

2. Is the audit trail outside the agent's reach?

Every action the agent attempts, whether it succeeds or fails, should be written to an append-only log outside the agent's control. This log must include what the agent tried to do, what policy was evaluated, whether it was allowed, and what the outcome was. If the log sits in a database the agent can reach, or a cloud account it holds permissions on, the agent can rewrite its own history.

3. Can you enforce policy before the agent acts?

Pre-execution enforcement is the difference between governance and monitoring. A dashboard that shows "the agent tried to modify 100 firewall rules and 95 of them succeeded" is monitoring. A policy engine that intercepted the request, evaluated the action against policy, and blocked the 5 suspicious ones before they executed is governance.

4. Is there a kill switch?

If the agent starts behaving unexpectedly (a bug is triggering it to take actions it shouldn't, or an incident response requires immediately halting its autonomous behavior), can you disable it without waiting for the next deployment cycle?

5. How do you detect if the agent itself is compromised?

If the agent's API key is leaked or the agent process is compromised, you need detection mechanisms specific to agent activity. This means baseline modeling of what the agent normally does, alerting on deviations from that baseline, and audit trails that would show a compromise in action. Generic SIEM monitoring might not catch an agent making slightly unusual but valid-looking API calls.

The meta-problem

The paradox underlying the agentic SOC is recursive: you're building AI agents to secure your infrastructure from other AI agents. The agent that defends needs to be defended against. That requires a governance layer that operates at the action level, independent of the agent's logic or the LLM's reasoning.

This governance layer isn't a model safety feature. It isn't prompt engineering. It's a control plane that sits between the agent's intention and the infrastructure it touches, enforcing policy at the moment the agent tries to interact with a tool.

Without it, you're trusting the agent to self-govern. In a security context, self-governance isn't governance. It's a vulnerability.

What to do before deploying an agentic SOC

Deploying agents into the SOC without governance puts the SOC's own credentials behind an unenforced policy. The operational checklist:

• Map agent capabilities: What tools can the agent access? What can each tool do? What would a worst-case misuse of each tool look like?
• Define baseline policies: What actions should the agent be able to take on its own? What requires human approval? What should be forbidden entirely?
• Verify enforcement architecture: Is policy enforced before the action executes or after? Is the audit trail outside the agent's control?
• Test the kill switch: Can you disable the agent immediately? How long does it take?
• Plan for escalation: When an agent action is ambiguous or risky, who reviews it and how quickly?

---

An agent operating inside the SOC needs the same governance as an agent deployed anywhere else, and it holds the SOC's own credentials while it waits for one.