THOR-SEC

Agent security case study · Case Studies

LLM Agent Control Plane

A deterministic control boundary for tool-connected LLM agents, with authorization kept outside the model and mapped to automated tests.

implemented-and-tested · Implemented and tested reference implementation

Problem

Tool-connected language-model agents can turn generated text into actions with real effects. If the model itself is treated as the authority, prompt injection, retrieved content, or a bad model decision can become an authorization decision.

Why common approaches fall short

  • Prompt instructions are not an authorization boundary. A model can ignore, reinterpret, or be induced to override them.
  • Schema validation proves structure, not permission. A well-formed tool call can still be unauthorized.
  • Sensitive actions need provenance, role, tenant, and approval checks that do not depend on model judgment.

THOR-SEC approach

The reference implementation puts a deterministic control plane between model output and simulated tools. The model proposes an action; the broker, policy engine, provenance checks, approval gate, tenant checks, and output filter decide whether the action can proceed.

Audit logging records allow and deny decisions with redaction, and the protected path is compared with a deliberately vulnerable simulation path.

Evidence

  • The repository maps security invariants to 293 automated tests, including deny-by-default behavior, broker authority, provenance enforcement, approval gates, tenant isolation, output filtering, audit logging, and refusal to execute a real shell.
  • Release v0.3.0 documents a validation gate covering the test suite, Docker/Compose validation, repository and policy checks, Bandit, pip-audit, CodeQL, Gitleaks, Trivy, and SBOM generation.
  • The project includes a FastAPI interface, CLI demonstrations, deployment reference profiles, defensive-control documentation, a threat model, and operator guidance.

Limitations

  • This is a local, simulated defensive reference implementation, not a drop-in production service.
  • It does not execute real shell commands, send real email, scan networks, or call production LLM APIs by default.
  • Production deployment still requires enterprise identity, persistence, key management, DLP, observability, deployment hardening, and operational review.
  • Release checksums are documented as unsigned and do not provide signed artifact provenance.

Current status

Implemented and tested reference implementation

Implemented reference architecture with tested security invariants. Production integration and operational validation remain outside the demonstrated scope.

Artifacts