An agentic security operations centre is one where AI agents take response actions, not only triage them. That is the whole of the distinction. An agent that reads alerts, correlates them, enriches them and writes a recommendation changes how fast a human decides. An agent that isolates a host, blocks an indicator, disables an account or revokes sessions changes the production estate by itself. The first is an analysis problem. The second is an authorization problem, and it arrives the day someone asks whether the agent can act on what it found.
Which actions cross the line?
Incident response has a containment, eradication and recovery phase, and it is the phase where a decision has an effect on systems in use (NIST SP 800-61 Rev. 2, section 3). The typical agent-reachable set is short, and it sorts by two things: whether the action can be undone, and what class of target it touches.
| Action | Undo | Why the target class matters |
|---|---|---|
| Enrich, look up, query | Nothing to undo | Read paths still leak if the result leaves the building |
| Revoke sessions | Reversible, disruptive | An administrator or executive account is a different event |
| Block indicator | Reversible | An allowlisted partner address is an outage |
| Disable a user | Reversible, visible | Disabling the wrong account during an incident is the incident |
| Isolate a host | Reversible, expensive | A test workstation and a domain controller are not one action |
| Delete or quarantine data | Often irreversible | This is where an error stops being recoverable |
The useful question about each row is not how confident the model is. It is whether the action, on that target, is entitled to run at all right now.
What makes a SOC agent different from other agents?
It reads attacker-controlled text as its job. The alert body, the ticket comment, the email sample, the file name, the process command line, the threat intelligence note: all of it is authored partly by the adversary. Prompt injection, where content the model reads is treated as instructions, is therefore not an edge case in a SOC. It is the input (OWASP LLM01:2025, MITRE ATLAS AML.T0051). ATLAS also catalogues the follow-on step as its own technique, the adversary steering an agent into invoking a tool it already holds (AML.T0053).
Two consequences follow, and they run in opposite directions.
Over-response. An injected instruction that looks like remediation is the most valuable payload in a SOC. Disable defences is already a catalogued adversary technique (T1562), and so is removing the evidence (T1070). An agent with response authority can be asked to perform both, in your own change window, with your own credentials, and it will look like ordinary work.
Suppressed response. The other outcome is quieter. Text that persuades the agent that an alert is benign produces no action and no record of a decision not to act. Nothing shows up in a dashboard of actions taken.
How is an agentic SOC run without taking that bet?
- Grade by reversibility and target class, not by model confidence. What you grade as routine, you have accepted the agent may do on a wrong reading.
- Bound the routine actions. Per target class and per hour. A rate limit is the difference between a mistake and an outage.
- Refuse what no rule covers. An action outside the catalogue should be refused rather than graded down, and the refusal should be recorded.
- Hold the irreversible ones for named people. Two named on-shift approvers signing the exact action, with the hold expiring into nothing. The failure modes of that gate are in human-in-the-loop for AI agents.
- Keep credentials out of the agent. Otherwise every control above is advisory. See AI agent credentials.
- Record every outcome, refusals included. After an incident the question is which actions ran, under which rule, approved by whom.
Where does it fail?
- Propose-only forever. The pilot works, the agent recommends, an analyst still opens three consoles. Time saved at triage is spent again at execution.
- Approval fatigue at three in the morning. Gate everything and the gate gets switched off. Gate the irreversible actions only.
- Approvals in the orchestrator. A playbook approval step governs that playbook. It does not see the agent that calls the EDR API directly, or the assistant inside the ticketing tool, or the next agent someone ships.
- A second path to the same system. One gated route and one ungated key is one ungated key.
- Identity systems answering the wrong question. Access management says where an agent may connect. It does not say whether this action, on this target, was entitled to run. That gap is agent authorization.
- Obligations no tool discharges. NIS2 requires incident handling policies and a reporting timeline to the authorities, with an early warning inside 24 hours (Directive (EU) 2022/2555, Articles 21(2)(b) and 23). No authorization layer reports an incident for you.
- Autonomy beyond the task. An agent holding more function than its job needs is the same defect as anywhere else: excessive agency.
What does ZIFFER change on the floor?
ZIFFER puts a decision between the agent's proposal and your systems. Every tool call is a proposal graded against the policy you signed: routine and reversible actions are granted and executed, irreversible or high impact ones are held for a quorum of two named humans who sign the exact bytes that will run, and an action no rule covers is refused and recorded. The agent holds no credential on your detection, identity or network systems, so the injected proposal and the correct one meet the same table. The worked policy table, the nine example proposals and the evidence a SOC lead hands upward are on the SOC page. What it does not do is detect anything, make triage more accurate or replace your existing tooling, and the injection specific reading is in prompt injection in the SOC.