Building the Execution Engine: Designing Agents That Act Intelligently in the SOC Stack

Section 1 — Why SOCs Need an Execution Layer

Most SOCs stop one step short of completion. Their pipelines collect, enrich, and correlate alerts inside a SIEM or SOAR, but when the pattern is obvious and time is measured in seconds, everything still pauses for a human click. The detection layer has context, the response tools have power, but there’s no bridge in between that can decide and act with minimal latency.

That missing bridge is the execution agent. It isn’t another dashboard or workflow tool; it’s a lightweight service built to sit quietly behind the SIEM, subscribe to confirmed detections, and execute well-defined actions through integrated controls. The agent closes the “detection-to-response” gap that slows every traditional SOC, especially when analysts are overloaded or alerts are repeating known patterns.

A SOAR playbook can isolate a host automatically, but it usually does so through a pre-defined workflow: a rule triggers, a sequence runs, and the same set of actions follow. The execution agent, by contrast, operates closer to the data stream and applies policy-bound, context-aware logic—evaluating confidence, risk, and recent history before it acts.

Architecturally, it’s not complex. You already have the ingredients:

• A SIEM that correlates Zeek, OpenEDR, and firewall telemetry into structured detections.
• APIs on those same tools capable of taking direct action.
• A small, auditable service that reads one stream and writes to the other.

That service becomes the reflex of the SOC. It acts when the pattern is certain, waits when it’s not, and always reports what it did. Over time, it learns which interventions actually reduced dwell time and which added noise.

Adding an execution agent doesn’t replace analysts—it gives them margin. Instead of clearing known fires, they spend time investigating the ones still unknown. The SOC becomes faster, quieter, and more predictable without surrendering control.

Section 2 — Core Components of an Execution Agent

Before building one, it helps to define what the execution agent is for and what remains human territory.

At Full Tilt Cyber, we draw the line this way:

The agent handles:

• Multi-vector or low-confidence correlations. It reasons across Zeek, OpenEDR, and firewall data—linking a suspicious connection with a rare process event—even when the pattern doesn’t match a known signature.
• Business-context-sensitive activity. It can pause, enrich, and verify context before acting; if an executive’s laptop shows data-exfiltration behavior, the agent flags it for deeper verification rather than quarantining outright.
• Lateral-movement hypotheses. It reconstructs timelines across hosts and users, highlighting potential pivots and prompting containment when confidence exceeds threshold.
• Process feedback and adaptation. When it detects repeated scenarios requiring analyst intervention, the agent generates candidate policies or procedural templates for review—shortening the time it takes to transform experience into automation.

The analyst handles:

• Novel attack techniques or zero-days. Patterns that fall outside existing detection logic and require new analytical models.
• Incident coordination and response direction. Determining business impact, prioritization, and high-level containment strategy when multiple systems are affected.

This division doesn’t reduce the analyst’s role—it refocuses it. The agent automates judgment inside the known, while the analyst extends the boundaries of what’s knowable. Over time, that partnership accelerates the SOC’s learning cycle: what once required days of playbook tuning inside a SOAR becomes near real-time adaptation within the agent model.

1 — Event Interface

The agent’s first role is to consume intelligence from the SIEM without introducing latency. It connects through an API subscription or message queue (Kafka, RabbitMQ, or OpenSearch alert streams). Events arrive as structured JSON containing correlation ID, confidence, severity, and enrichment metadata.

A robust interface automatically:

• Filters noise below confidence thresholds.
• Deduplicates similar alerts across sensors.
• Manages rate limits to prevent cascading load.

This ensures the agent acts only on confirmed detections, not transient anomalies.

2 — Decision Engine

This is the reasoning core. Each event is evaluated against current policy definitions and environment context. The decision engine calculates a response score using:

• Detection confidence from the SIEM.
• Asset or user criticality.
• Historical activity trends.
• Feedback weighting from previous outcomes.

The result is a structured decision object—a self-contained record with recommended action, justification, rollback, and next review point.

3 — Policy Store

All agent actions are authorized by policies stored in a version-controlled repository. Each policy defines:

• Trigger conditions – e.g., “ransomware detection with confidence > 0.9.”
• Permitted actions – isolate host, block IP, disable account.
• Escalation thresholds – when to defer to a human review.
• Rollback logic – how to reverse or verify a change.

Policies evolve continuously through analyst feedback and agent self-observation. When similar patterns repeat, the agent drafts or proposes new policies for review—something a SOAR system would normally require manual rule engineering to implement.

4 — Action Connectors

Connectors give the agent reach. They integrate directly with network, endpoint, and identity systems through authenticated APIs—firewalls, EDR platforms, IAM, or cloud-native controls. Each action is idempotent, logged, and timestamped. If a command fails, the connector retries with exponential backoff and reports its state to the SIEM for full traceability.

5 — Feedback Telemetry

Every agent decision feeds telemetry back into the SIEM and learning pipeline:

• Verification: confirm execution succeeded.
• Effectiveness: measure whether the threat was actually contained.
• Adaptation: update confidence weighting or suggest policy refinements.

This feedback is what transforms automation from static to evolutionary. Analysts no longer need to draft playbooks line by line; the agent itself produces structured insight into which automations should exist next.

1 — Position in the SOC Architecture

The agent lives behind the SIEM and in front of the enforcement layer—between detection and orchestration. It consumes the SIEM’s correlated detections, applies policy-driven logic, and executes actions in seconds through connected control systems.

It’s not another workflow platform. It’s the decision muscle between the SIEM’s brain and the SOAR’s limbs.

[Network/Endpoint Sensors]
    ↓
[Zeek | OpenEDR | Firewall Logs]
    ↓
[Filebeat | Log Collector]
    ↓
[SIEM (OpenSearch)]
    ↓
[Execution Agent Layer]
    ↓
[Action Connectors: Firewall | EDR | IAM | Cloud Controls]
    ↓
[SOAR & Analyst Feedback]
    ↖
[Learning + Policy Adaptation Loop]
        

The SIEM continues to correlate and contextualize. The SOAR continues to coordinate incident response. The agent focuses on the middle ground—the decision gap that slows containment.

2 — Tackling Problems Too Complex for SOAR

SOAR platforms shine at predictable tasks—resetting passwords, blocking IPs, or opening tickets. Where they stumble is in correlated ambiguity: events that cross domains, depend on environmental context, or demand adaptive weighting.

An execution agent addresses exactly that. It evaluates network, host, and behavioral data simultaneously, using confidence models and contextual logic to determine whether an event deserves immediate containment or further observation. It learns from every result, creating new policy candidates automatically.

In other words:

• A SOAR executes what it’s told.
• An agent learns what’s worth executing.

That difference removes the backlog of “almost-automatable” work that analysts spend hours repeating—verifying lateral movement chains, cross-checking host integrity, or confirming anomalies that fit familiar risk profiles.

3 — Removing Analyst Decision Fatigue

Analysts spend most of their time deciding what not to do: whether to quarantine, escalate, or wait. Each decision may take seconds, but multiplied across hundreds of alerts, it becomes a cognitive tax that drains focus from real investigation.

The execution agent is designed to absorb that fatigue. It manages the middle layer of decisions that once required constant analyst triage:

• Confidence-based containment (“Is 0.85 enough to isolate the host?”)
• Contextual risk validation (“Does this process normally communicate over port 8080?”)
• Timeline reconstruction (“Has this IP appeared in the same segment before?”)

Instead of handing those questions to a human, the agent computes them deterministically using rules, heuristics, and accumulated feedback from prior outcomes. Analysts intervene only when an event exceeds policy scope or contradicts learned behavior.

The result is a SOC that spends less time deciding and more time understanding. Analysts move upstream—to analysis, pattern discovery, and system improvement—while the agent carries the weight of mid-tier operational decisions.

4 — Integration with the SOC Stack

The agent’s connections are straightforward:

• SIEM: provides correlated detections and enrichment data.
• Agent: consumes, evaluates, and enforces policy.
• SOAR: orchestrates cross-team workflow and evidence management.
• Analyst: reviews, corrects, and teaches.

This layout doesn’t disrupt established tools; it strengthens them. The agent acts as the execution bridge—transforming detection into containment at machine speed, while preserving visibility and human oversight through the SIEM and SOAR interfaces.

5 — Continuous Adaptation

Every decision the agent makes becomes a learning opportunity. Successful containment strengthens the model’s confidence; false positives lower it. Over time, this creates an autonomous feedback mechanism that accelerates the creation of new policies—automating emerging response patterns long before a SOAR playbook would be written.

The effect is cumulative:

• Analysts gain mental bandwidth for complex incidents.
• Automation evolves faster and safer.
• The SOC learns as a whole, every single day.

Section 4 — Communication and Data Models

An execution agent only works if it speaks the same language as the systems it connects. That means strict data models, predictable message flow, and guardrails that prevent automation from drifting into chaos. Communication design is as critical as logic design.

1 — Event Ingestion Model

The agent doesn’t scrape dashboards or query APIs on a timer. It subscribes. All correlated detections from the SIEM are published to a queue or stream — Kafka, RabbitMQ, or an OpenSearch alert channel. Each event is structured as JSON or protobuf with standardized fields:

FieldDescriptionevent_idUnique correlation or detection identifiertimestampUTC timestamp of correlationconfidence0.0–1.0 float from correlation logicseverityDiscrete classification (low/medium/high/critical)src_host, dst_hostPrimary identifiers for affected assetstagsContextual labels from Zeek, OpenEDR, firewallrecommended_actionSuggested containment steppolicy_scopeName or hash of applicable policy

The agent consumes events in order, validates schema integrity, and caches them locally to ensure no loss during network interruptions. Duplicates are deduplicated by event_id.

2 — Decision and Policy Evaluation Model

Once the event passes ingestion, it’s converted into a decision object. This is an internal data structure containing:

• Event metadata.
• Matched policy ID.
• Calculated action confidence.
• Action path (which connector to use).
• Rollback instructions.

Policies are referenced by version and signature to guarantee traceability. The agent never executes free-form logic; all actions must link to an approved policy in the policy store.

When no direct match is found, the event is escalated into a learning state — held for analyst review, labeled, and later used to generate new candidate policies.

3 — Action Execution Model

All agent-to-system interactions use authenticated REST or gRPC calls through connectors. Each command includes:

FieldDescriptioncommand_idUUID for traceabilityactione.g., “block_ip”, “isolate_host”, “disable_user”targetSystem or endpoint identifierreasonDecision context summaryttlTime-to-live (auto-rollback window)

Responses are validated against expected status codes and logged immediately. If a command fails, the connector retries with backoff and marks the action as “pending verification.” Every command, success or failure, is mirrored into an actions index inside the SIEM for auditing.

4 — Feedback and Learning Flow

After action confirmation, the agent emits a feedback event back into the SIEM stream:

FieldDescriptiondecision_idLinks feedback to the original decisionoutcomesuccess / failure / overriddenexecution_latency_msTime from correlation to actionanalyst_overrideBoolean flagconfidence_adjustmentΔ value for model tuning

These feedback events drive the agent’s retraining process. A scheduled batch job or lightweight ML pipeline processes outcomes, comparing predicted vs. actual results and adjusting weights inside the decision engine. If an analyst overrides an action, that feedback is prioritized during retraining to reduce recurrence.

5 — Governance and Safety Mechanisms

Communication is bound by three non-negotiables:

• Idempotency — repeating a message cannot cause duplicate enforcement.
• Audibility — every event, decision, and action is logged with immutable IDs.
• Reversibility — any command can be rolled back via policy-defined rollback logic.

Additionally, rate limits and circuit breakers protect critical infrastructure. If the agent misbehaves—too many actions in too short a time—it trips a containment circuit, pauses automation, and alerts analysts for review.

6 — Data Retention and Security

All message traffic between components uses mutual TLS with short-lived tokens. Sensitive payloads (like endpoint identifiers or user data) are masked when stored for training. Decision logs follow the same retention policy as the SIEM—usually 90–180 days—after which they’re summarized into anonymized training data.

The goal is not just reliability, but confidence through transparency. Every component, message, and state change can be reconstructed from logs without guesswork.

With this model, the execution agent doesn’t act as a black box—it acts as a disciplined participant in the SOC’s data fabric. Every byte has lineage, every action has evidence, and every decision can be replayed for accountability.

Section 5 — Policy Enforcement and Safety Mechanisms

In an execution agent, power and restraint must be built in the same place. Policy enforcement is what makes automation trustworthy — defining exactly what may happen, how fast, and under what verification. The agent’s authority begins and ends with these rules.

1 — Policy Hierarchy

Policies operate in layers, each governing a different scope of authority:

LayerScopeExampleGlobalUniversal safety controlsNever isolate more than 5% of hosts in one subnet within 60 minutesDomainCategory-specificFirewall blocks allowed only on external IP rangesContextualAsset or user classExecutive laptops require analyst confirmation before account suspensionAction-levelSingle enforcementBlock IP x.x.x.x if confidence > 0.85 and rule origin = “known IOC”

Policies are versioned, signed, and distributed through a controlled update process—usually a GitOps-style repository synchronized with the agent fleet. Each version includes policy hash and changelog to maintain full lineage.

2 — Policy Parsing and Execution Flow

When the agent receives a detection event:

1. It matches the event’s metadata against all applicable policies.
2. It selects the most specific rule (contextual > domain > global).
3. It evaluates action eligibility — checking time windows, rate limits, and dependencies.
4. If approved, it executes the action through the connector layer.
5. It records the decision, result, and policy version used for full traceability.

Each policy evaluation generates a decision token — an immutable record linking that single action to the logic that permitted it. If the action is later disputed, the token reconstructs every variable: data inputs, policy state, timestamps, and outcome.

3 — Safety and Control Mechanisms

Unchecked automation can do as much harm as an attacker. To guard against runaway decisions, the agent enforces multiple built-in brakes:

• Rate Limits: Cap how many identical actions can occur within a window (e.g., max 3 quarantines per minute).
• Confidence Thresholds: Require minimum confidence values to trigger automated containment.
• Circuit Breakers: Automatically suspend automation in a domain if failure rate exceeds threshold or anomaly volume spikes unexpectedly.
• Two-Stage Actions: Sensitive actions (account lockout, VLAN isolation) can require dual confirmation — agent preps and queues the command, but waits for analyst validation.
• Rollback Windows: Each executed command has a defined TTL (time-to-live). If not confirmed as “effective” within that period, the agent rolls back changes automatically.

4 — Exception Handling

Not all events fit policy neatly. The agent classifies exceptions in three types:

• Policy Miss: No applicable rule found — escalate for analyst labeling and future policy generation.
• Conflict: Multiple policies apply with different outcomes — defer to higher precedence or analyst confirmation.
• Execution Failure: Action rejected by downstream system — mark as failed, retry within backoff limit, and report upstream.

These exceptions feed into the agent’s learning loop. The system tracks frequency, context, and outcome to refine future logic or propose new automation rules.

5 — Human Oversight and Policy Governance

Automation doesn’t mean absence of control — it means deliberate delegation. Analysts can:

• View live policy enforcement summaries.
• Pause individual policy categories.
• Approve or reject automatically generated policy proposals.
• Trigger immediate rollback on any recent action.

Governance dashboards pull from the agent’s decision logs, showing exactly what triggered each action, which policy authorized it, and whether containment succeeded.

Routine policy audits—monthly or after major incidents—verify that automation still aligns with organizational intent and regulatory boundaries (e.g., GDPR or NIS2 impact on user or asset handling).

6 — The Balance Between Authority and Adaptation

A well-designed agent acts decisively but never absolutely. Every enforcement must carry a return path — the ability to explain itself, undo itself, or improve itself.

That balance is the difference between automation that saves time and automation that silently causes damage. At Full Tilt Cyber, we build agents that act like disciplined operators: fast, predictable, and accountable.

Automation earns trust not through cleverness, but through control.

Section 6 — Feedback and Continuous Improvement

Automation without feedback is guesswork. A mature execution agent isn’t just fast—it’s self-aware enough to improve. Every decision it makes is data: whether containment worked, whether human review agreed, whether action timing or confidence calibration was right. That data drives the next iteration.

1 — The Feedback Cycle

Each time an agent executes an action or defers a decision, it produces a feedback record. That record flows through three channels:

1. Operational Metrics – latency, action success rate, rollback frequency.
2. Outcome Validation – whether the action resolved the issue or created false positives.
3. Analyst Input – manual overrides, comments, or reclassifications.

These inputs form a continuous signal for retraining. The agent doesn’t learn in isolation—it learns through evidence and correction, just like an analyst refining instinct through repetition.

2 — Confidence Adjustment

The most direct benefit of feedback is confidence recalibration. Each decision carries an initial confidence value (e.g., 0.87 for “likely lateral movement”). When an analyst validates that decision, or when follow-up telemetry confirms the threat was neutralized, the agent updates its confidence weights.

Successful detections raise the score; false alarms reduce it. Over time, the agent’s behavior curve smooths out—fewer unnecessary actions, faster containment for recurring patterns.

This process replaces the rigid “tune the threshold once a quarter” approach with adaptive calibration happening continuously.

3 — Policy Refinement

Feedback also produces policy proposals. The agent analyzes recurring patterns that required manual intervention and generates candidate policy templates. For example:

• Multiple low-confidence detections escalating to the same manual response → propose a new rule.
• Frequent false positives on a particular signature → suggest adding exception parameters.

These proposals appear in the analyst’s review queue as structured diffs: what changed, why it’s being suggested, and what supporting data exists. Once approved, the new policy is versioned, signed, and distributed across the agent fleet.

This makes the policy lifecycle iterative rather than bureaucratic. Instead of waiting for a SOAR engineer to author a playbook, the agent brings the next rule ready-made.

4 — Performance Scoring

To ensure automation stays beneficial, every agent maintains a performance profile—a statistical record of:

• Mean time to containment (MTTC).
• False-positive ratio.
• Analyst override frequency.
• Policy churn rate (how often policies are updated).

These metrics flow into SOC reporting and feed executive dashboards alongside traditional KPIs like mean time to detection (MTTD). It’s a clear signal of how well autonomy is performing relative to human labor.

If override frequency spikes, analysts know confidence is misaligned. If MTTC drops and containment success stays stable, automation is tuned well.

5 — Retraining Pipeline

Retraining can be manual or automatic, depending on environment maturity:

• Manual retraining happens during review sessions where analysts label historical data and confirm action accuracy.
• Semi-automated retraining integrates a lightweight ML pipeline that consumes outcome data, adjusts model weights, and publishes updated decision parameters to the agent fleet.

Each retraining cycle includes guardrails: version control, rollback capability, and automatic validation against historical incidents to ensure accuracy doesn’t regress.

6 — Building Institutional Memory

Perhaps the most valuable side effect of the feedback system is institutional memory. Every action, error, and correction becomes a structured lesson the SOC can reuse. Analysts rotate, tools evolve, but the agent retains what was learned—preserving context across time.

That’s how resilience scales. A SOC no longer starts from zero after each incident; it inherits the entire behavioral history of its automation.

7 — The End State

When feedback becomes culture, automation becomes intelligence. The execution agent transforms from a reactive script into an adaptive participant—measuring its impact, proposing improvements, and learning from its mistakes.

The end result is a SOC that doesn’t just act faster, but thinks faster as a system. Analysts guide strategy, the agent handles execution, and together they produce a security posture that strengthens with every event.

Section 7 — Closing: Why Execution Agents Redefine SOC Efficiency

A SOC’s success has always hinged on one metric: how fast clarity becomes action. Detection alone doesn’t win the fight; response does. The execution agent closes that gap—not by replacing analysts, but by giving them the mechanical intelligence to focus where humans add the most value.

Traditional automation follows a simple pattern: alert → playbook → action. It’s dependable but slow, and it ages badly—each new threat demands a new workflow. The execution-agent model replaces that rigidity with responsiveness. It evaluates context dynamically, acts within policy, and evolves based on measurable outcomes.

The result is a SOC that feels different from the inside:

• Analysts think strategically. They spend their time defining thresholds, not chasing them.
• Automation adapts in real time. Policies evolve from experience, not from paperwork.
• Executives see stability. Incident rates drop, audit evidence improves, and time-to-containment becomes predictable.

This is why we build agents at Full Tilt Cyber. They’re not a trend—they’re an architectural correction. SOCs don’t need more dashboards; they need reflexes. The execution agent provides them, translating detection into decisive, traceable, and self-improving action.

The future of cybersecurity isn’t hands-off; it’s hands-amplified. Analysts still steer the mission, but now the system drives itself through the routine terrain—fast, calm, and accountable.