Skip to content
Mordred

Threat model

Assume the traitor is inside.

An agent reads untrusted text and then acts through tools and providers. hermes-mordred adds policy checks at specific Hermes integration points. This page distinguishes what those hooks enforce from what still sits outside their boundary.

Who is trusted, who is not.

Trusted

  • Your operating system, user account, and Hermes-managed Python environment.
  • The local config.yaml and derived Mordred policy you review.
  • The installed hermes-mordred code and its registered Hermes hooks.
  • The selected native key backend: Secure Enclave or login Keychain on macOS, TPM 2.0 on Linux.

Not trusted

  • Agent instructions, prompt content, retrieved text, and tool arguments.
  • Remote inference providers and their endpoints.
  • Slack, Discord, and every network between this process and those services.
  • Direct sockets, unwrapped executables, and runtimes outside Mordred's registered hooks.
  • The Mordred maintainers: the package sends us no run telemetry.

Untrusted

  • Agent & prompts
  • Gateways
  • Remote inference
  • The network in between
  • Direct sockets outside registered hooks

Assumed hostile, or one prompt away from it.

Policy — hermes-mordred

  • Strict provider + endpoint approved?
  • Protected route evidence ready?
  • Bound E2E context valid?
  • At-rest runtime key available?

Strict mode blocks covered violations. Lenient mode may warn and route failures may fall back to clearnet.

Trusted — local base

  • macOS — Secure Enclave preferred / login-Keychain fallback
  • Linux — TPM 2.0 required

Native wrapping keys stay behind the helper. Portable MRKV export is a separate, passphrase-protected recovery mechanism.

Registered hooks mediate covered operations; they are not an OS-wide sandbox

Current controls, and how you inspect them.

Each row names the enforcement point and the closest operator-visible command. These commands report configuration and state; they are not a proof against a compromised host.

Control Enforcement boundary Inspect / configure
Strict inference policy checks provider identity and endpoint. The LLM guard resolves the live provider, applies cloud allowlisting and endpoint rules, and checks the declared parent harness. It does not inspect prompt text for secrets. hermes-mordred policy show
Bound Slack and Discord contexts require ENC:v3. Authenticated, context-bound keys cover direction, platform, channel, and thread. Mandatory-E2E commands and replies refuse plaintext or missing context. hermes-mordred extension pair
Integrated Hermes traffic follows the selected process route. Mordred manages Tor, VPN, or clearnet environment and transport hooks for the current process. It is cooperative routing, not a host firewall. hermes-mordred network status
Native wrapping keys stay behind the platform helper. macOS prefers a non-exportable Secure Enclave key and may use a login-Keychain software key; Linux requires TPM 2.0. Portable MRKV backup is a separate, explicit recovery path. hermes-mordred status
At-rest protection state is visible per target. On macOS, env, config, memory, and workspace report whether they are on, off, paused, exposed, sealed, or open. Transparent target lifecycles are inactive on Linux. hermes-mordred encryption status

What strict-mode refusal looks like.

These refusal paths apply at the hooks Mordred controls. The default policy is lenient, so choose strict explicitly when warnings and clearnet fallback are not acceptable.

A protected route is down

With strict policy, failed Tor or VPN evidence refuses the integrated request or session. Lenient and off modes may warn, audit, and fall back to clearnet.

Strict network.bringup_failed

A cloud endpoint is not approved

Strict mode refuses an unresolved provider, a provider outside the allowlist, or an endpoint that does not match the provider rules before the request is sent.

Strict policy.strict.cloud_not_allowlisted

Memory protection cannot open safely

When memory encryption is armed, a missing runtime key or unsupported Hermes seam causes memory reads and writes to refuse instead of creating plaintext.

Strict memory runtime guard unavailable

The local audit log.

The mode-0600 log starts as plaintext NDJSON. After audit-key provisioning it uses the line-oriented MRAL format with AES-GCM. Writers use bounded fields and omit secret values, but logging is best-effort and same-user tampering is not detected in this release.

PATH
~/.hermes/mordred/audit.log
FORMAT
NDJSON before keyvault · MRAL after
CIPHER
AES-GCM · native-wrapped DEK
ROTATION
daily or 10 MiB · retained 30 days

hermes-mordred audit tail

09:14:02 ALLOW on_session_start · provider is allowlisted
reason: policy.strict.cloud_allowlisted
09:17:41 BLOCK on_session_start · cloud provider refused
reason: policy.strict.cloud_not_allowlisted
09:22:08 FALLBACK network.bringup_failed · tor → clearnet
lenient/off behavior; strict raises instead
09:26:19 ALLOW keyvault.backup_export · encrypted MRKV snapshot
reason: keyvault.backup_exported

What this does not protect against.

The honest half of a threat model. If your adversary is on this list, hermes-mordred is not enough on its own.

  1. 01

    A compromised OS, user session, or runtime.

    Root or same-user malware can invoke helpers, alter configuration, disable plugins, or read plaintext while it is in use.

  2. 02

    Direct sockets and unwrapped executables.

    Network routing is process-scoped and cooperative. Code that bypasses registered transports or starts an unwrapped process can bypass it.

  3. 03

    Prompt-content data-loss prevention.

    The LLM guard validates provider, endpoint, and harness identity. It does not detect credentials or redact sensitive text inside a prompt.

  4. 04

    An append-only or externally anchored audit history.

    AES-GCM protects encrypted records, but another process running as the same user can rewrite or delete the log. Audit append errors are best-effort and do not become a universal execution gate.

  5. 05

    Plaintext while protected data is actively used.

    Config and workspace protection are at-rest lifecycles. A managed process or mounted workspace needs a plaintext view, and an unclean exit can leave config materialized until the next clean cycle.

  6. 06

    Traffic analysis or a recipient who leaks.

    Tor or VPN can change the observable route and E2E protects gateway payloads, but timing, volume, endpoints, and recipient behavior remain outside Mordred's control.

Found a hole in this?

Open a GitHub issue with what you found, what you expected, and the smallest reproduction you can share.

Open a GitHub issue Report sensitive details privately