Mural

title: Mural Skill Security Model description: STRIDE threat model for the Mural skill covering browser callback, Mural API egress, on-disk cache, caller input, and Azure SAS uploads author: microsoft/hve-core ms.date: 2026-10-28 ms.topic: reference estimated_reading_time: 18 keywords:

• security

• STRIDE

• mural

• oauth

• threat model

<!-- markdownlint-disable-file -->

Mural Skill Security Model

This document records the STRIDE threat model for the Mural skill (the mural package under scripts/mural/). The model is organized by trust bucket: Browser to Loopback (B1), CLI to Mural endpoints (B2), On-disk cache (B3), CLI caller process (B4), and CLI to Azure Blob SAS upload (B5). Each bucket enumerates all six STRIDE categories with the in-code mitigations that address them. Assets and adversaries are enumerated first because credential-storage docs (docs/agents/mural/credentials.md) reference them by id. Acknowledged enterprise readiness gaps are listed at the end of the document.

See also: repo-wide STRIDE model. This skill participates in the repository-wide threat model at docs/security/security-model.md and is registered in its Skill Security Models section. The Authorization Code + PKCE login flow implemented by _run_login is enumerated there as the OA threat family in § OAuth Authentication Threats; that section is authoritative for the current membership of the family. Each OA row cites Mural's published OAuth documentation at https://developers.mural.co/public/docs/oauth (verified 2026-05-10) and pins residual-risk expectations against published RFC behavior. Gap G-EOP-2 below (refresh-token non-rotation) is verified correct against that source.

Two boundary facts in this document are load-bearing for that catalog. First, the browser launch performed by _run_login passes only the authorization URL, which carries client_id, redirect_uri, state, code_challenge, and the requested scopes; the PKCE code_verifier never leaves the process, so a hostile default-browser handler is a same-uid concern already recorded as ADV-a rather than a separate OA threat. Second, the callback handoff from the loopback receiver to the OAuth client is synchronous and in-process: serve_forever runs on a thread inside the same interpreter and the result is read from shared memory after state is compared with secrets.compare_digest. There is no inter-process boundary on that handoff, so it carries no distinct residual beyond the B1 rows below.

Executive Summary

The Mural skill is a local Python CLI dispatched through argparse. It authenticates to Mural with OAuth 2.0 Authorization Code + PKCE, caches access and refresh tokens in the OS keyring (or a 0600 file fallback), and makes authenticated HTTPS calls to the Mural REST API. Its highest-risk behaviors are at-rest credential storage on the operator workstation and the browser-mediated OAuth login flow; both are mitigated in code, with residual gaps tracked in the gap register. The skill runs no public listener (the loopback receiver is single-shot and bound to 127.0.0.1) and treats all Mural-authored content returned through the CLI as untrusted. An agent caller invokes the CLI through a terminal tool, so stdout and stderr are captured into agent context. B4 names the protected diagnostic, machine-readable envelope, top-level error, record-output, ordinary API, token, and SAS channels. Remaining direct print and LOGGER calls are outside a package-wide guarantee and require sink-specific review.

Security Posture Overview

Contents

• System Description

• Trust Boundaries

• Assets

• Adversaries

• Bucket B1: Browser → Loopback

• Bucket B2: CLI → Mural endpoints

• Bucket B3: On-disk cache

• Bucket B4: CLI Caller Process

• Bucket B5: CLI → Azure Blob SAS upload

• Enterprise Readiness Gaps

• References

System Description

Components

1. scripts/mural/ Python package — the argparse CLI entry point and command handlers. The package exports a MCPInvalidParamsError validation exception retained for CLI helper compatibility; it implements no JSON-RPC framing, tool dispatch, or stdio server loop.

2. OAuth login flow (_run_login) — opens the browser to Mural's authorization URL and runs a single-shot loopback receiver at http://127.0.0.1:8765/callback.

3. Token store and credential file — per-user cache (mural-token.json, mode 0600) and mural.{profile}.env, or the OS keyring backend.

4. REST and token clients — separate urllib.request no-redirect openers for the canonical Mural API and OAuth token endpoint.

5. Azure Blob upload client — a dedicated no-redirect opener for capability-bearing SAS PUT requests.

Data Flow

flowchart TD
    subgraph HOST["Operator Workstation (trust zone)"]
        CLI["mural CLI (argparse)"]
        LOOP["Single-shot loopback<br/>127.0.0.1:8765"]
        STORE["Token store + credential file<br/>(keyring or 0600 file)"]
    end
    subgraph BROWSER["Default Browser (user-driven)"]
        TAB["Mural consent page"]
    end
    subgraph MURAL["Mural SaaS (network boundary)"]
        AUTH["Authorization server"]
        API["REST + token endpoints"]
    end
    subgraph AZURE["Azure Blob Storage (capability boundary)"]
        BLOB["Signed upload destination"]
    end
    CLI -->|"open auth URL + PKCE challenge"| TAB
    TAB -->|"redirect with code + state (HTTP loopback)"| LOOP
    LOOP -->|"code"| CLI
    CLI -->|"code + verifier (HTTPS, no-redirect)"| AUTH
    AUTH -->|"access + refresh tokens"| CLI
    CLI -->|"persist"| STORE
    CLI -->|"Bearer request (HTTPS, no-redirect)"| API
    API -->|"widget content (untrusted)"| CLI
    API -->|"SAS upload capability"| CLI
    CLI -->|"asset PUT (HTTPS, no-redirect)"| BLOB

Trust Boundaries

Boundary Diagram

┌───────────────────────────────────────────────────────────────┐
│ TRUST BOUNDARY: Operator Workstation                          │
│  ┌─────────────┐  ┌────────────────┐  ┌────────────────────┐  │
│  │ mural CLI   │  │ Loopback recv  │  │ Token store +      │  │
│  │ (argparse)  │  │ 127.0.0.1:8765 │  │ credential file    │  │
│  └─────────────┘  └────────────────┘  └────────────────────┘  │
└───────────────┬───────────────────────────────┬───────────────┘
                │ open browser                  │ HTTPS (TLS)
    ┌────────────▼───────────┐      ┌────────────▼───────────────┐
    │ BOUNDARY: Browser      │      │ BOUNDARY: Mural SaaS       │
    │  Mural consent page    │      │  Auth server + REST API    │
    └────────────────────────┘      └────────────────────────────┘
                                             │ signed upload URL
                                  ┌──────────▼───────────────┐
                                  │ BOUNDARY: Azure Blob     │
                                  │  capability-bearing PUT  │
                                  └──────────────────────────┘

Boundary Descriptions

Assets

Adversaries

Bucket B1: Browser → Loopback

The Authorization Code + PKCE flow opens the user's default browser at Mural's authorization URL and runs a single-shot loopback HTTP listener at http://127.0.0.1:8765/callback (overrideable via MURAL_REDIRECT_URI) to receive the authorization code.

Spoofing

A hostile page in the browser could attempt to deliver a forged authorization response.

• The login flow generates a random state parameter and rejects callbacks whose state does not match (see scripts/mural/ _run_login).

• The loopback handler verifies the inbound Host header matches the bound loopback address before processing the request (see scripts/mural/ _LoopbackHandler).

Tampering

The loopback channel is plaintext HTTP because TLS to 127.0.0.1 is not available without a custom CA.

• The listener is bound to 127.0.0.1 only (never 0.0.0.0 or ::), so on-host code is the only writer (see scripts/mural/ _start_loopback_server).

• The redirect URI is validated to require an IPv4 loopback literal; localhost and [::1] are rejected (see scripts/mural/ _validate_redirect_uri).

Repudiation

Not applicable. The loopback exchange is a synchronous, in-process step; no persistent action is taken until the token endpoint exchange in B2 succeeds. The handoff from the receiver to the OAuth client crosses no process boundary: serve_forever runs on a thread inside the same interpreter and the authorization code is read from the shared result object once received is set and state has been compared with secrets.compare_digest.

Information Disclosure

A hostile referrer or shoulder surfer could attempt to capture the authorization code.

• PKCE binds the authorization code to a per-flow code_verifier, so a captured code cannot be redeemed without the verifier held only by this process (see scripts/mural/ _generate_pkce_pair, _verify_pkce).

• The loopback responds with a minimal HTML success page that contains no token material.

Denial of Service

The listener is a process-local socket and an attractive target for local resource exhaustion.

• The loopback server is single-shot: it accepts one request, completes the handshake, and shuts down (see scripts/mural/ _start_loopback_server).

• The login wait has a bounded timeout and the bound port is fixed so collisions surface immediately as MuralError("port 8765 already in use; set MURAL_REDIRECT_URI") rather than silently rebinding (see scripts/mural/ _run_login).

Elevation of Privilege

A request to an unexpected path or method could attempt to drive the handler into unintended code paths.

• The handler accepts only GET /callback and rejects every other method or path with HTTP 404 (see scripts/mural/ _LoopbackHandler).

Risk Rating

Bucket B2: CLI → Mural endpoints

All REST and OAuth token-endpoint calls target https://app.mural.co/... over TLS using the Python standard library (urllib.request).

Spoofing

• TLS certificate validation is enforced by the stdlib default SSLContext, which uses the system trust store.

Tampering

• TLS protects request and response bodies in transit.

• OAuth token, authenticated API, and Azure SAS upload calls use dedicated no-redirect openers, so a 30x cannot silently retarget credential-bearing or capability-bearing requests (see scripts/mural/ _NoRedirect).

Repudiation

• Token responses are persisted with obtained_at timestamps so auth status can show when each profile was last refreshed (see scripts/mural/ _apply_refresh).

Information Disclosure

• Bearer tokens are sent only in the Authorization header to the canonical https://app.mural.co/api/public/v1 base. Custom remote bases and absolute operation URLs are rejected before credential loading. Explicit HTTP loopback testing requires MURAL_ALLOW_INSECURE_API=1 and a port.

• The token-endpoint opener blocks 30x responses, preventing a hostile redirect from leaking refresh tokens to a non-Mural origin (see scripts/mural/ _NoRedirect).

• The token response parser requires Content-Type: application/json and reads through a capped-size reader; a non-JSON response (HTML error page, captive portal, etc.) raises a typed error rather than being parsed as a token (see scripts/mural/ _parse_token_response).

Denial of Service

• Mural API rate limits surface as MuralAPIError codes; the CLI honors Retry-After for transient failures and exits EX_TEMPFAIL (75) so callers can back off.

• Response bodies are read through a capped reader so a runaway upstream cannot exhaust memory.

Elevation of Privilege

• The default scopes are read-only. Write scopes are granted only when auth login --write is invoked, and the granted scope set is recorded in the token store and re-checked at dispatch time before any destructive call. The dispatch check evaluates the same profile the request uses: --profile, then MURAL_PROFILE, then the token store's active_profile, then default (see scripts/mural/ _require_scope).

• MURAL_SCOPES allows callers to drop scopes per session for least-privilege automation.

TLS posture

The skill performs Mural API, OAuth token, and Azure SAS upload calls through dedicated urllib.request opener instances. There is no custom ssl.SSLContext, HTTPSHandler, cafile/capath argument, or certificate-pinning callback anywhere in the skill source. Operators inherit Python's default HTTPS behavior end to end, with the implications below.

• Trust store. Validation uses the default ssl.create_default_context() (created implicitly by urllib), which loads the system trust store. On Linux this is OpenSSL's default cert paths; on macOS Python links against the system Security framework when built with the official installer; on Windows Python loads the SChannel certificate store.

• Custom CA roots. The skill does not expose a CLI flag for a CA bundle. Operators behind a TLS-inspecting proxy or with an internal CA must export the standard Python/OpenSSL environment variables (SSL_CERT_FILE, SSL_CERT_DIR) before invoking python -m mural. The skill does not depend on requests, so REQUESTS_CA_BUNDLE has no effect.

• Certificate pinning. None. Validation relies entirely on the system trust store. This is acceptable for a public SaaS endpoint (app.mural.co) but is recorded as G-TLS-1 below for customers whose policy requires explicit pinning.

• mTLS. Not supported by the skill. Mural's API does not require client certificates, so this is not currently a gap.

• TLS version and ciphers. Inherited from the host Python build's OpenSSL. The skill makes no calls to set_ciphers, minimum_version, or set_alpn_protocols. Hosts requiring TLS 1.2 floors or specific cipher suites must enforce them through the Python build or system OpenSSL configuration.

• FIPS posture. Inherited from the host Python build. The skill does not attempt to detect or enforce FIPS mode; operators on FIPS-validated systems should confirm their Python and OpenSSL builds before relying on the skill in regulated environments.

Risk Rating

Bucket B3: On-disk cache

Refresh and access tokens are persisted to a per-user cache file (mural-token.json) with a sibling lockfile (<path>.lock). The cache is schema version 2 and supports multiple named profiles.

This bucket also covers the per-user credential file (mural.{profile}.env) created by mural auth bootstrap at $XDG_CONFIG_HOME/hve-core/ (POSIX) or %APPDATA%\hve-core\ (Windows), which holds the Mural OAuth client_id and client_secret. It is loaded at runtime via _autoload_credentials only when the matching environment variables are unset.

Storage backend variants

MURAL_CREDENTIAL_BACKEND selects how A2 (refresh tokens) and A3 (client secrets) are persisted at rest. The four modes share the same wire-level behavior but have distinct at-rest threat surfaces:

• auto (default). Prefers the OS keychain when the keyring package and a usable backend are present; falls back to the file backend when the keychain is unavailable, or when the keychain is reachable but holds no usable credentials while the file backend does. Either fallback emits a one-shot WARN per profile. The chosen backend is reported by mural auth status.

• keyring. OS keychain only (macOS Keychain, Windows Credential Manager via DPAPI, freedesktop SecretService). Defends ADV-c (backup/sync exfiltration) and partially defends ADV-d (stolen device) when the keychain requires explicit unlock. Does not defend ADV-a.

• file. Plaintext-at-rest under 0600 permissions, with the protections described below. Defends only ADV-d on encrypted-at-rest disks. Does not defend ADV-a or ADV-c.

• env-only. Reads credentials only from process environment; never persists. Suitable for ephemeral CI runners. Removes ADV-c entirely; introduces a Repudiation gap (no obtained_at history is recorded).

mural auth migrate round-trips credentials between backends and verifies the destination read before deleting the source (when --cleanup --force is passed).

In auto mode the auth write flows (mural auth login, mural auth bootstrap) also promote file-backend credentials into a reachable-but-empty keyring automatically: each key is written and verified with a read-back before the file copy is removed, moving plaintext-at-rest material behind the keychain and restoring the ADV-c defense above. On any write or verification failure the keyring writes are rolled back and the file copy is kept. Promotion is skipped in non-interactive contexts (MURAL_NONINTERACTIVE=1 or CI=true).

Devcontainer, Codespaces, and WSL2 contexts inherit the host operator's trust; the keyring backend may be unavailable inside the container, in which case auto falls through to the file backend or env-only and the resulting backend is logged at startup.

Spoofing

• Each profile entry is bound to its registered client_id. A token loaded under a profile whose client_id does not match the current MURAL_CLIENT_ID is rejected at load time so a token issued for a different OAuth app cannot be silently reused (see scripts/mural/ _select_profile).

Tampering

• All writes go through os.open(O_WRONLY | O_CREAT | O_EXCL, 0o600) followed by os.replace so partial writes are never observed.

• Concurrent CLI writers serialize through an advisory lock on the sibling <path>.lock file (fcntl.flock on POSIX, msvcrt.locking on Windows), preventing interleaved writes from corrupting the v2 envelope (see scripts/mural/ _acquire_cache_lock).

• mural auth login refuses to overwrite stored credentials when the token-store profile has an access or refresh token, or when a MURAL_REFRESH_TOKEN is stored in the keyring or credential file. Client ID and client secret are app configuration and never count, so mural auth setup followed by mural auth login proceeds without --force (see scripts/mural/ _profile_has_session).

• mural auth status and mural doctor report a login only when the active profile has a validated token-store record with an access or refresh token, because authenticated requests refresh only from that record. A backend MURAL_REFRESH_TOKEN still blocks an unforced login but is reported separately as backend_refresh_token instead of as a usable session (see scripts/mural/ _profile_has_usable_session).

• Without --force, login refuses to overwrite an existing session and fails closed before starting OAuth when the token store or credential file cannot be read or validated. After OAuth returns, login re-checks the profile under the same lock as the write, so a session created by a concurrent login is kept rather than overwritten. Replacing an unreadable or incompatible store, which discards every profile in it, requires --force; a valid store keeps unrelated profiles (see scripts/mural/ _cmd_auth_login).

• Residual: keyring and credential-file reads are not atomic with the token-store lock, so a refresh token written to a backend after the final check is not detected. Tokens minted by a login whose write is skipped are discarded locally but remain valid server-side until they expire or are revoked (see G-EOP-1 and G-EOP-2).

• The credential-file parser performs no shell expansion and no $VAR interpolation; values are stored verbatim and matching surrounding quotes are stripped without further processing (see scripts/mural/ FileBackend._read_all). A tampered file therefore cannot escalate to subprocess execution via parsed values.

Repudiation

• Each profile entry records obtained_at and the granted scope set so the source and freshness of any cached credential is auditable from the cache file alone.

• mural auth status reports credential_file (resolved path) and credential_file_exists (boolean) so operators have a stable, scriptable view of which credential source the runtime would load (see scripts/mural/ _cmd_auth_status).

Information Disclosure

• The cache file is created with mode 0600 on POSIX. On Windows the file lives under %LOCALAPPDATA%\hve-core\ whose default ACL grants access only to the owning user.

• The lockfile is created with mode 0600 and contains no token material; it exists only as the target of the platform's advisory-lock primitive.

• The credential file is created with mode 0600 and _check_credential_file_perms refuses to load it on POSIX when the mode includes any group or world bits. The check can only be bypassed by setting MURAL_ENV_FILE_RELAXED=1, which is intended for ephemeral CI containers and should never be set on a workstation. MURAL_ENV_FILE overrides the resolved path so callers can point the loader at a managed secrets-mount location instead of the default XDG path.

• Env-only mode (MURAL_CREDENTIAL_BACKEND=env-only) does not write to disk and therefore inherits whatever protection the host process environment provides; operators are responsible for not leaking the environment into job logs or child-process dumps.

Denial of Service

• The lockfile is intentionally never deleted to avoid the unlink/recreate race that would let a concurrent writer hold a lock on a stale inode. A stale lock is harmless: the next acquirer simply takes the advisory lock on the same file.

• Cache reads are bounded by file size and parsed through json.loads with no recursion limits relaxed.

Elevation of Privilege

• The schema-version check refuses to load a v1 cache as v2 without running the explicit _migrate_v1_to_v2 path, which preserves the client_id binding contract (see scripts/mural/ _migrate_v1_to_v2).

• MURAL_KEYRING_BACKEND accepts a module.path.ClassName string and instantiates it via importlib.import_module + getattr. This is intentional for tests and unusual desktop environments, but it permits arbitrary class instantiation from any importable module. An attacker who can already set environment variables for the CLI process can already do worse, so this is rated EoP-Low; treat the env var as part of the operator-controlled trust surface.

Secret rotation: The client_secret outlives any access token. To rotate, revoke the old credential at https://app.mural.co/account/api first, then re-run mural auth bootstrap to write fresh values. Deleting the credential file alone does not revoke the secret server-side.

Known limitation: plaintext at-rest. Both the token store and the credential file are mode-0600 plaintext on disk. Stdlib symmetric encryption with a passphrase prompt was rejected because it would prompt on every CLI invocation (defeating the UX goal) and storing the passphrase next to the ciphertext provides no real defense over POSIX permissions. The credential file shares the same threat model as the token store; users who require stronger at-rest protection wrap invocations with an out-of-band secrets manager (dotenvx, sops exec-env, pass) as documented in SKILL.md.

Risk Rating

Bucket B4: CLI Caller Process

The skill exposes Mural operations through local CLI commands. The caller process controls argv, environment variables, stdin, stdout, and stderr, and the CLI treats that process as operator-controlled.

Spoofing

• The CLI has no network listener or attach surface. It runs as the invoking OS user and trusts the caller's argv and environment.

• The executable identity comes from the installed package or python -m mural; operators should invoke the intended environment explicitly when multiple checkouts or virtual environments exist.

Tampering

• Command arguments are parsed by argparse; command handlers validate identifiers, URLs, JSON bodies, profile names, area layouts, tags, hyperlinks, and pagination cursors before issuing HTTP requests.

• JSON arguments are parsed through _parse_json_arg, which requires object-shaped payloads where a command expects a request body and raises a typed validation error before any API call.

• Environment-driven paths and profiles are normalized through dedicated helpers so null bytes, unsupported profile names, and unsafe credential-file permissions fail before credential loading.

Repudiation

• Commands emit deterministic exit codes for validation failures, authentication failures, temporary upstream failures, and unexpected errors so automation can attribute failures to the invoking step.

• The in-process idempotency cache (_IDEMPOTENCY_CACHE, bounded LRU of 128 entries) returns the original result for duplicate command/idempotency-key pairs within a process lifetime, so repeated create calls cannot be silently double-attributed. The cache is process-local and not persisted across restarts.

Information Disclosure

• Diagnostic messages routed through _emit are filtered by _redact. The token, authenticated API, and Azure SAS transport URL debug logs also redact their URL values before calling LOGGER.debug (see scripts/mural/ _redact).

• Machine-readable envelopes routed through _emit_json or _emit_json_error apply structural _redact_payload masking before serialization. The structured stderr helper preserves valid JSON and its key set.

• The top-level main() handlers redact credential-autoload, auth-scope, typed MuralError, and unexpected-error text. The four structured error envelopes route through _emit_json_error.

• Record output routed through _emit_record or _emit_records preserves Mural-authored text and field names. It masks only complete Azure Blob SAS URLs that pass _validate_asset_url and contain a sig query parameter.

• Ordinary Mural API errors carry a bounded, redacted _error_excerpt. Token parsing, refresh, authorization-code exchange, and Azure SAS upload failures discard opaque response bodies and retain only HTTP status, a stable internal error code, and a static message.

• Remaining direct print and LOGGER calls do not inherit a package-wide redaction guarantee. Each such sink requires review against the data it emits.

• Mural-authored text (sticky notes, textboxes, descriptions, attachments, etc.) returned through CLI output must be treated as untrusted by downstream automation. Mural-sourced text is JSON-encoded output data and is never interpolated into model instructions by the CLI.

Denial of Service

• HTTP response bodies from Mural are read through _read_capped with MURAL_MAX_BODY_BYTES (default 16 MiB) so an upstream that streams an unbounded body cannot exhaust the process.

• Pagination uses explicit page-size limits and bounded cursor parsing so malformed cursors or oversized page requests fail locally.

• Bulk update commands support --atomic and bounded retry behavior for tag merge conflicts so partial upstream failures produce structured summaries instead of unbounded loops.

Elevation of Privilege

• Write commands dispatch through _require_scope; there is no CLI path that skips the granted-scope check before calling a write endpoint.

• Existing-widget update, delete, and bulk update require the AI-authored tag by default. --force-human is an explicit per-call override before mutating a human-authored widget.

• Dry-run capable commands return structured previews without invoking the underlying Mural API call.

Local destination control plane

The registry loader uses yaml.safe_load, rejects malformed or unsafe entries, and applies the optional override by destination identifier before dispatch. Destination and action intent must both be explicit. The dispatcher can invoke only an adapter supplied by the caller and contains no real destination-system adapter.

The shipped registry and projection map contain no presentation destination. Removing the reserved route adds no HTML executor or alias and changes no generic dispatch, credential, source-hydration or metadata-writeback authority.

Hydration treats widget text as untrusted source data, preserves text and htmlText, and keeps derived hierarchy, tag, lineage, authorship, and partial-state metadata in separate fields. Existing-widget writeback accepts only tags, hyperlink, and parentId. Local test-double evidence does not establish native Mural behavior or real destination effectiveness.

Risk Rating

Bucket B5: CLI → Azure Blob SAS upload

Asset-upload commands obtain a signed URL from Mural and send the asset body through the dedicated _SAS_OPENER.

Spoofing

• _validate_asset_url requires HTTPS and an allowed Azure Blob host before the signed capability is used.

Tampering

• TLS protects the upload body and signed query in transit. The dedicated opener refuses all redirects, so the PUT body and capability cannot be retargeted.

Repudiation

• Upload failures produce typed operation results and deterministic exit codes. The skill does not provide a tamper-evident upload audit sink (G-REP-1).

Information Disclosure

• The SAS query is a bearer capability and is redacted from diagnostics. It is never copied into the API Authorization header or normal command output.

Denial of Service

• Each upload uses a finite request timeout and makes one attempt when a redirect is returned. Upstream availability and large local asset costs remain bounded by the caller's operation.

Elevation of Privilege

• The signed URL defines the provider-granted upload capability. Host validation and redirect refusal prevent the CLI from broadening that authority to another destination.

Risk Rating

Enterprise Readiness Gaps

The following gaps are known limitations of the current implementation. They are recorded here so operators can make informed deployment decisions and so contributors have a clear backlog of hardening work. Severity ratings are the project's own assessment and are not equivalent to a CVSS score.

For an active issue tracker entry covering these gaps, see the hve-core issues list.

References

• STRIDE Threat Model

• OWASP Top 10 for LLM Applications

• Mural OAuth documentation (verified 2026-05-10)

• RFC 6749 — OAuth 2.0, RFC 7636 — PKCE, RFC 6819 — OAuth Threat Model

• Repository security model

🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.