# Hermes `documental-agent` Target Remediation Runbook version: `sibyla-documental-remediation/1.2-prototype-ws2025` Target host: `EC2AMAZ-NTPJCNO` Target OS: `Windows Server 2025 Datacenter` Current decision: `CANONICAL_DOCUMENTAL_ACCEPTANCE=FAIL` ## Objective Remediate the existing `documental-agent` profile so that Sibyla can run financial document extraction under a dedicated, unprivileged Windows identity without exposing gateway, application, database, storage, or channel privileges. The existing profile configuration is migrated selectively into a dedicated runtime. The current `SOUL.md` in this repository is authoritative; the remediation script installs it and verifies its declared instruction version. Do not create a duplicate profile merely to satisfy an obsolete command name. Sibyla uses the canonical CLI profile name `documental-agent`. Prototype checksum policy: transported and installed instruction files are not accepted or rejected by checksum. Hashes may be captured as non-blocking diagnostics; effective loading, declared version, isolation, and behavioral acceptance are the gates. These changes require an authorized Windows deployment operator. The Hermes `orquestrador` may collect evidence after remediation, but must not use its own Administrator context to declare the controls satisfied or silently broaden its privileges to perform the remediation. ## Current observed failures - Hermes and `documental-agent` run from Administrator's `HERMES_HOME`. - No dedicated local Windows extraction identity exists. - The profile has terminal, code execution, file, web, browser, memory, session, delegation, cron, skills, and computer-use capabilities enabled. - Administrator's process environment contains business and infrastructure credential variables. - No restricted launcher, ACL boundary, benign extraction, prompt-injection, concurrency, or timeout evidence exists. ## 1. Preserve evidence and choose names Before changing the target: 1. Back up the existing Administrator Hermes home using the established backup process. 2. Record the current `documental-agent` profile details and tool inventory without printing credential values. 3. Record the existing `documental-agent/SOUL.md` path and declared version as pre-remediation evidence. Install the current authoritative instructions from this repository and verify that a fresh process loads `sibyla-documental/2.3`. 4. Keep `documental-agent` as the canonical profile name. Do not rename or duplicate it unless a separately reviewed deployment dependency requires that change. ## 2. Dedicated Windows identity An operator must create a dedicated local or managed service identity for extraction, for example `GottSibylaDocumental`, subject to the organization's naming policy. Required properties: - not a member of Administrators, Remote Desktop Users, deployment groups, or gateway/operator groups; - no interactive or RDP logon in normal operation; - only the batch/service logon right required by the selected launcher; - no access to Administrator's user profile or Hermes home; - no PostgreSQL role, Sibyla API identity, SharePoint/Graph identity, Nextcloud identity, or channel credentials; - password or managed identity material held only by the Windows service/task mechanism, never in source, prompts, scripts, command lines, or application configuration. Record the account SID, assigned groups, granted logon right, and explicit denied or absent privileges as sanitized deployment evidence. ## 3. Isolated Hermes home Use the approved dedicated non-user-profile location: `C:\SibylaApps\Documental-agent` Set `HERMES_HOME` explicitly for the restricted launcher. Do not rely on Administrator's process or user environment. Provision only what `documental-agent` needs: - the profile configuration and verified `SOUL.md`; - the selected inference model/provider configuration; - the minimum protected inference-provider authentication needed to call the model; - no gateway configuration, Baileys session, Mattermost/email credentials, Sibyla secrets, database settings, storage credentials, other profiles, memories, sessions, hooks, plugins, or MCP configuration. Inference authentication is permitted because extraction requires model access, but it must be protected from prompt/tool access and must not share business credentials. ## 4. Tool policy Apply tool changes while the restricted `HERMES_HOME` is active and verify them in a fresh process. For the CLI platform, disable at least the currently observed prohibited toolsets: ```powershell hermes -p documental-agent tools disable --platform cli ` web browser terminal code_execution video image_gen video_gen x_search tts ` skills todo memory session_search clarify delegation cronjob computer_use ``` Keep only the minimum document-reading/OCR/vision and local QR-decoding capability required by the tested invocation. QR decoding must operate only on the staged input and must not enable network or process execution. Generic `file` access should be disabled unless the production document input mechanism requires it. If it is required, Windows ACLs must limit what the account can read and write, and the canonical suite must prove those limits dynamically. After changes, record `hermes -p documental-agent tools list`. A prompt instruction or claimed policy is not a substitute for the effective inventory. ## 5. Environment isolation Launch extraction with a newly constructed, allowlisted environment rather than a copy of Administrator's environment. It may include only values required by Windows, Hermes, per-job paths, non-secret model selection, and the protected inference authentication mechanism. Specifically exclude all Sibyla, PostgreSQL, Graph, SharePoint, Nextcloud, gateway, Mattermost, email, WhatsApp, admin-seeding, Git, crawler, dashboard, and unrelated cloud variables. Verify names and presence without logging values. ## 6. Filesystem layout and ACLs Use a deployment-owned root such as: ```text C:\ProgramData\GOTT\Sibyla\Documental\ profile\ jobs\\input\ jobs\\output\ jobs\\temp\ evidence\ ``` Required access model: - deployment administrators and SYSTEM retain administrative control; - the restricted identity can read its profile and each supplied job input; - it can write only the corresponding job output, usage, and temporary locations; - it cannot read application configuration, original-document storage, channel homes/sessions, database material, other user homes, or deployment sources; - the Worker identity can stage input and collect output but cannot read inference authentication from the restricted Hermes home; - completed per-job staging is removed according to the retention policy. Use disposable canaries to test denied access. Never use or print a real secret as a test value. ## 7. Restricted launcher design Before claiming production readiness, document how Sibyla Worker requests an extraction under the restricted identity without possessing or placing that identity's password in code or environment variables. Acceptable designs include a dedicated Windows service/broker running as the restricted identity or another reviewed Windows service/task mechanism that: - accepts only local authenticated job requests; - validates and confines all input/output paths; - constructs the sanitized environment; - starts a fresh non-resumed Hermes process per job; - supports two concurrent jobs with separate directories; - enforces timeout, output-size, and child-process cleanup; - returns extraction JSON and usage metadata without granting Hermes access to PostgreSQL or Sibyla credentials. An Administrator console command is not an acceptable production launcher. A one-off Scheduled Task may be used to execute the F0 acceptance under the restricted identity, but it does not by itself implement the later Worker integration. ## 8. Pre-acceptance verification Before rerunning the canonical suite, verify all of the following: - `whoami` reports the dedicated restricted identity; - the effective `HERMES_HOME` is the isolated home; - `hermes -p documental-agent --help` resolves successfully; - `SOUL.md` is loaded from the intended profile and declares `sibyla-documental/2.3`; - the legacy instruction file remains absent/not loaded; - the effective tools satisfy the allowlist; - the environment contains no forbidden credential names or values; - readable/writable and denied canary ACL checks behave as intended; - a fresh process can reach only the approved inference provider path; - no existing Administrator Hermes session is resumed. ## 9. Canonical rerun After remediation, rerun the target-host suite using `documental-agent` as the canonical profile name. Execute benign extraction, prompt injection, concurrency two, timeout, and cleanup under the restricted identity. Do not convert skipped tests into PASS. Return the full machine-readable result block and supporting evidence. F0 remains NO-GO until `CANONICAL_DOCUMENTAL_ACCEPTANCE=PASS` is supported by observed evidence.