THOR-SEC

Research archive

Research

Formal publications, open-source research tools, and field notes, newest first. Design proposals are labeled as such; nothing here claims results it has not measured.

Papers

  1. · preprint · version 1.0.0 · CC BY 4.0

    Memory-Egress Cryptographic Interlock (MECI)

    A Hardware-Enforced Capability-Separation Model for AI Memory Security.

    A hardware-oriented formal model for separating unreleased protected AI memory from gated egress authority. It defines reflexive-transitive high-to-egress reachability, a generation-checked SafeOpen transition, cryptographic epoch non-resurrection, and noninterference modulo authorized release. The finite safety core is checked by TLC and an independent reference checker; no hardware prototype or measured performance is claimed.

    Cite this paper 
    Thor, T. (2026). Memory-Egress Cryptographic Interlock: A Hardware-Enforced
Capability-Separation Model for AI Memory Security (1.0.0). Zenodo.
https://doi.org/10.5281/zenodo.23109676

  2. · preprint · version 1.0.0 · CC BY 4.0

    Mission-Invariant Architecture Morphing (MIAM)

    Service-Graph Reconfiguration Against Post-Access Reconnaissance, with Cryptographic Epoch Isolation and Mission-Domain State Continuity.

    A design proposal and formal model. It develops a reconnaissance-transfer model, architecture-distance measures, a recurrence-aware retention model, per-epoch cryptographic isolation, a graph-delta-driven State Continuity Firewall, and an ablation-based evaluation protocol. It reports no empirical results.

    Cite this paper 
    Thor, T. (2026). Mission-Invariant Architecture Morphing: Service-Graph
Reconfiguration Against Post-Access Reconnaissance, with Cryptographic Epoch
Isolation and Mission-Domain State Continuity (1.0.0). Zenodo.
https://doi.org/10.5281/zenodo.23001045

Tools and reference implementations

  1. · AI assurance

    Model Identity Verifier

    Analyzes LLM identity drift, suspicious provider or route mismatch, and downgrade or substitution signals, and separates behavioral checks from cryptographic attestation.

  2. · LLM infrastructure

    BoundaryLayer

    Defensive lab comparing vulnerable and hardened infrastructure boundaries after a model or agent is tricked.

  3. · agent security

    LLM Agent Control Plane

    Keeps authorization, policy, approvals, provenance checks, filtering, and audit logging outside the model. Agents propose; the control plane decides.

    Authorization flow
    Authorization flow for tool-connected LLM actions The agent proposes an action. A separate control plane evaluates policy and identity. Allowed actions run through tools; denied actions are blocked. Both outcomes are written to an audit log. Agent proposes action Control plane: policy + identity allow deny Tool executes Action blocked Audit log

  4. · security architecture

    Security Stack Engineering (SSE)

    Multi-layer reference architecture for governed and measurable security operations. Background: the SSE essay.

  5. · risk quantification

    Impact Forecast Algorithm (IFA)

    Bayesian-inspired implementation for updating material-impact probability from explicit evidence likelihood ratios.

Field notes

  1. · detection engineering

    OAuth anomaly baseline

    Flags unusual OAuth grant behavior by comparing per-user token activity against a rolling baseline, surfacing uncommon client and scope combinations for review.

    Splunk SPL

    index=authentication sourcetype=oauth:token
| stats dc(client_id) AS clients dc(scope) AS scopes count BY user
| eventstats avg(count) AS avg_grant stdev(count) AS stdev_grant BY user
| eval threshold=avg_grant+(3*stdev_grant)
| where count > threshold AND clients > 1

  2. · AI security

    LLM agent authorization boundary

    The agent may propose an action, but authorization belongs in a separate policy layer with identity context, allow and deny decisions, and audit logging.

    Pattern

    decision = control_plane.authorize(action, identity, policy)

if decision.allowed:
    audit.log(action, identity, "allowed")
    tool.execute(action)
else:
    audit.log(action, identity, "blocked")