How patch execution actually works

The honest truth: Mythal's architecture for executing patches through enterprise tools is real and built. The integrations themselves — actually connecting to a customer's Tanium server, calling SCCM, dispatching Ansible jobs — are real connectors that need to be configured per customer. Today, in the demo environment, those connectors run in simulation mode with realistic timing and realistic API result payloads. The plumbing is there. The credentials and target endpoints are the customer-specific part you wire in during the proof.

Think of it like this: the execution engine, the policy gate, the approval workflow, the reasoning trace, the compliance evidence emission — all real, all running. The last mile — driving Tanium or SCCM in customer-specific ways — is connectors that get configured during the POC, not invented during the POC.

2How a patch executes — full lifecycle

3What a real driver actually looks like (in code)

Drivers are small Python classes. Each one wraps one tool's API. Here's the shape of the Tanium driver:

class TaniumDriver(PatchDriver):
    """Drives the Tanium platform for endpoint patching."""

    def __init__(self, config):
        self.base_url = config["base_url"]      # e.g. https://tanium.csx.internal
        self.api_token = config["api_token"]    # pulled from Vault
        self.signing_key = config["signing_key"]
        self.verify_tls = config.get("verify_tls", True)

    def apply_patch(self, asset, patch):
        # 1. Look up the target endpoint in Tanium
        endpoint = self._find_endpoint(asset.hostname)

        # 2. Create an action that installs the KB
        action_id = self._create_action(
            target=endpoint.computer_id,
            package=patch.kb_id,           # e.g. KB5004945
            sense_id=patch.tanium_sensor,
        )

        # 3. Poll until complete (with timeout + backoff)
        status = self._wait_for_action(action_id, timeout=600)

        # 4. Return structured result for the Execution record
        return ExecutionResult(
            tool="tanium",
            action_id=action_id,
            status=status.outcome,         # success / failed
            exit_code=status.exit_code,
            stdout_tail=status.last_log_lines,
            duration_s=status.duration_seconds,
        )

    def rollback(self, asset, patch):
        # Reverse the action — uninstall + restart
        ...

The same shape applies to all the other drivers. Each one wraps one tool. The Executor calls driver.apply_patch(asset, patch) and gets back a structured result.

4What we have today — be honest

5How rules and policies get configured

Policies are stored as OPA bundles (Open Policy Agent — the standard policy-as-code system). You write rules in Rego, the standard policy language. Here's what a real policy rule looks like:

package mythal.execution

# Critical Cyber Systems require dual approval, no auto-apply, ever
require_dual_approval["ccs"] {
  input.asset.is_ccs == true
}

# OT zones require dual approval AND maintenance window
require_dual_approval["ot"] {
  input.asset.env == "OT"
}

# Auto-apply allowed only for low-criticality IT with high-reliability patch
auto_apply_eligible {
  input.asset.env == "IT"
  input.asset.criticality != "Critical"
  input.patch.reliability_score >= 0.85
  input.canary_peer_available == true
  not require_dual_approval[_]
}

# Block anything during configured blackout windows
blocked["blackout"] {
  some w
  input.current_time >= data.blackout_windows[w].start
  input.current_time <= data.blackout_windows[w].end
}

The policy bundle is loaded into Mythal at startup. When the customer wants to change a rule — for example, "never auto-apply on Friday afternoons" — an engineer edits the bundle, runs opa test to validate, and pushes. Mythal hot-reloads.

You can also configure simpler things through the Policy Studio console page without writing Rego:

• Which asset classes require approval
• Which approver groups handle which scope
• Maintenance window schedules per zone
• Blackout periods (board meetings, peak revenue weeks)
• Which tools handle which OS class

6Tools we drive (and what method each one uses)

7Can we show this in the POC? — yes, and here's how

8What to say when CSX asks "is this real or simulated?"

"The execution engine, the policy gate, the approval workflow, the rescan loop, the compliance evidence emission — all real, all running on Azure today. What you're seeing on screen is real Python code making real database transactions and emitting real audit records.

The last mile — the integrations to your specific Tanium server, your SCCM, your Ansible — those are connectors that get configured during a proof. The drivers are written. The interface is stable. What's customer-specific is the endpoint URL, the credentials in your Vault, and the asset routing rules.

During a POC, we'd wire up one of your patch tools — probably the most API-accessible one — and demonstrate one real patch landing end-to-end through Mythal. That's enough to prove the pattern. The remaining connectors get configured during onboarding, not during the proof."

9Realistic POC scope

Phase	What we connect	What's still simulated
POC kickoff	Mythal appliance stood up in your lab. Read-only Qualys connection (or whichever scanner you use). Read-only CMDB connection.	All patch tools still in simulation mode while we get the read paths working.
POC mid	One patch-tool driver wired to a real lab instance (typically Ansible Tower because it's API-friendly). One real plan executes end-to-end against a lab Windows or Linux server.	Other patch tools still simulated. Production assets out of scope.
POC close	Compliance evidence PDF reviewed by your auditor. End-to-end trace shown. Lab patch landed and verified.	Production wiring deferred to onboarding phase.
Onboarding (post-POC)	All remaining patch-tool drivers wired. Approval routing to your real ServiceNow / Slack / email. Vault integration. Production assets enrolled in waves.	Nothing — full production.

10Is this too complex for the demo? — no, not if you frame it right

You're not selling a finished product. You're selling an execution architecture that's already built, with the customer-specific last mile being a known, scoped piece of work.

The demo should:

• Show the simulated execution flow (visually impressive, all real code, just synthetic API payloads)
• Show the Compliance evidence PDF (real PDF, real reasoning trace)
• If asked "is this hitting our real Tanium?" — answer with the verbatim answer in section 8 above
• Offer to show the driver code in a real editor if they want to see the integration layer

If they're satisfied with the simulation + the driver code, you've made the sale. If they want to see one connector actually hit a real system, that's exactly what the POC delivers.