Governing Self-Improving Agents Under the EU AI Act and NIST AI RMF

A self-improving agent is an "AI system" under the EU AI Act, and high-risk only when its use falls into Annex III or a regulated product. Learning changes you pre-determine and document are not a "substantial modification"; unforeseen ones can make you a new provider. NIST AI RMF adds the operating model: inventory, change management, monitoring and a way to switch it off.

This guide reads the primary texts so you do not have to. It quotes the articles that matter for agents that change over time, maps them to NIST subcategories, and walks through a concrete control setup using Nous Research's open source Hermes Agent as the worked example, because its documentation spells out exactly which parts of the agent change and which configuration keys gate them. The same pattern applies to any agent that learns from use.

Key takeaways

• Under Article 3(1) of Regulation (EU) 2024/1689, an AI system is one that "may exhibit adaptiveness after deployment". A self-improving agent fits that definition squarely. Whether it is high-risk depends on its use (Article 6 and Annex III), not on the fact that it learns.
• The Act deals with learning in three places: Article 3(23) defines "substantial modification" as a change "not foreseen or planned" in the initial conformity assessment; Article 15(4) requires high-risk systems that "continue to learn" to address feedback loops; Article 43(4) says pre-determined changes documented under Annex IV point 2(f) are not a substantial modification.
• Who counts as provider matters more for agents than for most software. Under Article 25, a deployer that makes a substantial modification to a high-risk system, or changes the intended purpose so that a system becomes high-risk, takes on the provider's obligations.
• Dates have moved. The Commission's AI Act page (updated 19 October 2026) says the AI Omnibus entered into force on 27 July 2026 and pushes Annex III high-risk obligations to 2 December 2027 and Annex I product obligations to 2 August 2028. GPAI model obligations have applied since 2 August 2025, transparency obligations since August 2026.
• NIST AI RMF 1.0 already names the controls a learning system needs: GOVERN 1.6 (inventory), MEASURE 2.4 (monitor in production), MEASURE 3.1 (track emergent risks), MANAGE 2.4 (supersede, disengage or deactivate) and MANAGE 4.1 (post-deployment monitoring including "change management").
• The practical control set is the same in both: version skills, memory and prompts, gate writes behind human review where the risk warrants it, keep logs, and be able to roll back or stop the agent.

Why a self-improving agent is a governance problem

Most governance programmes were designed around a model that is trained, evaluated, frozen and shipped. A self-improving agent breaks the "frozen" step. The weights usually stay the same, but the behaviour still changes, because the agent rewrites the text it reads before every task.

Hermes Agent is a useful concrete case. It is an MIT licensed open source agent from Nous Research (github.com/NousResearch/hermes-agent). Its release feed showed v0.22.5 as the latest stable release on 23 October 2026, with release candidates and canary builds published the same day, so treat any version number here as a dated snapshot. Its documentation describes four things that change as it runs:

The skills documentation is explicit that this is the design: when the agent "figures out a non-trivial workflow, it saves the approach as a skill for future reuse." The system prompt asks it to do so after a multi-step workflow, after finding a working path past errors, and after a user correction.

That is the governance question in one sentence. If the procedure an agent follows on Tuesday was written by the agent on Monday, who approved it, where is the record, and can you put Monday back?

When is a self-improving agent an "AI system" under the EU AI Act?

Article 3(1) of Regulation (EU) 2024/1689 defines an AI system as "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments."

An LLM agent that plans, calls tools and runs shell commands meets every element. It operates with autonomy, it infers outputs from inputs, and its outputs (commands, files, messages) influence physical or virtual environments. Recital 12 adds that adaptiveness "refers to self-learning capabilities, allowing the system to change while in use." Note the word "may": adaptiveness is not required to be an AI system, but a system that has it is plainly within scope.

The Commission's guidelines on the AI system definition (6 February 2025) help with borderline software; for an LLM agent the harder questions are whether it is high-risk, who the provider is, and what learning after deployment does to your obligations.

When does its use make it high-risk?

Learning does not make a system high-risk. Use does. Article 6 gives two routes:

1. Article 6(1), products. The system is a safety component of a product, or is itself a product, covered by the Union harmonisation legislation in Annex I, and that product needs third-party conformity assessment. An agent controlling machinery or a medical device workflow could land here.
2. Article 6(2), Annex III use cases. Annex III lists areas including biometrics, critical infrastructure, education, employment and workers' management, access to essential private and public services, law enforcement, migration and border control, and administration of justice. Annex III point 4(a), for example, covers AI systems "intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates."

Article 6(3) then carves out Annex III systems that do "not pose a significant risk of harm" because they perform a narrow procedural task, improve the result of a completed human activity, detect patterns without replacing human assessment, or perform a preparatory task. There is a hard stop: an Annex III system "shall always be considered to be high-risk where the AI system performs profiling of natural persons." Article 6(4) requires a provider relying on the carve-out to document that assessment before placing the system on the market.

For a self-improving agent, the classification trap is drift of purpose. A general coding agent deployed for developer productivity is not in Annex III. The same agent, after a few weeks of a team asking it to triage job applications and saving that procedure as a skill, may be performing an Annex III task. Nothing in the code changed; the learned skill library did. That is why the intended purpose needs to be written down and why skill creation should be reviewed against it.

What about the open source exemption?

Article 2(12) says the Regulation "does not apply to AI systems released under free and open-source licences, unless they are placed on the market or put into service as high-risk AI systems or as an AI system that falls under Article 5 or 50."

This protects the project releasing the code. It does not protect you once you put that open source agent into service for a high-risk purpose, or in a way that triggers Article 50. "Putting into service" in Article 3(11) includes supply "for own use in the Union for its intended purpose", so an internal deployment counts. If you run Hermes Agent, or any other open source agent, as a customer-facing chatbot on a messaging platform, the Article 50(1) duty to tell people they are interacting with an AI system applies regardless of the licence.

What the Act says about systems that keep learning

Four passages carry the weight, and their wording decides what you must document in advance.

Article 3(23): substantial modification

"'substantial modification' means a change to an AI system after its placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment carried out by the provider and as a result of which the compliance of the AI system with the requirements set out in Chapter III, Section 2 is affected or results in a modification to the intended purpose for which the AI system has been assessed;"

Two conditions must both hold: the change was not foreseen or planned, and it affects compliance with the high-risk requirements or changes the intended purpose. A planned, documented class of change does not meet the first condition.

Article 15(4): feedback loops

"High-risk AI systems that continue to learn after being placed on the market or put into service shall be developed in such a way as to eliminate or reduce as far as possible the risk of possibly biased outputs influencing input for future operations (feedback loops), and as to ensure that any such feedback loops are duly addressed with appropriate mitigation measures."

For an agent that writes its own memory and skills, the feedback loop is literal. The agent's output (a saved note, a saved procedure) becomes its input on the next session. If a wrong conclusion is saved, it is reloaded, reinforced and acted on. Hermes documents this mechanism directly: memory is injected into the system prompt as a frozen snapshot at session start, so a note saved today shapes every session from tomorrow.

Article 15(5) adds resilience against "attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities", including data poisoning. Persistent prompt injection through memory or skills is a form of it; our post on EU AI Act Article 15 and AI-specific attacks covers that paragraph.

Article 43(4) and Annex IV point 2(f): pre-determined changes

"For high-risk AI systems that continue to learn after being placed on the market or put into service, changes to the high-risk AI system and its performance that have been pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation referred to in point 2(f) of Annex IV, shall not constitute a substantial modification."

Annex IV point 2(f) asks for "a detailed description of pre-determined changes to the AI system and its performance, together with all the relevant information related to the technical solutions adopted to ensure continuous compliance". Article 13(3)(c) requires the instructions for use to state those pre-determined changes too.

Recital 128: what "learn" means here

Recital 128 explains the intent: changes that amount to "automatically adapting how functions are carried out" are not a substantial modification if they were "pre-determined by the provider and assessed at the moment of the conformity assessment", whereas a "change of operating system or software architecture" should trigger a new assessment.

Reading these together for an agent

The practical reading for a provider of a high-risk agent is a contract with yourself: describe in advance which artifacts the agent may change, within what bounds, with what checks, and how you will know when a change falls outside the envelope. Changes inside the envelope are covered by your original conformity assessment. Changes outside it are a new system.

This is a reasonable reading of the text, not an official interpretation. As far as we could find on 23 October 2026, the Commission has not issued agent-specific guidance on pre-determined changes.

Who is the provider and who is the deployer?

Article 3(3) defines a provider as anyone that "develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge." Article 3(4) defines a deployer as anyone "using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity."

A typical self-improving agent stack has three layers, each with its own party:

Scenarios

A team runs an open source agent internally for engineering work. It is an AI system, almost certainly not high-risk, and not exempt from Article 4 (AI literacy) or, where it talks to people outside the team, Article 50. Most high-risk obligations do not apply. NIST AI RMF and ISO/IEC 42001 are the right tools.

A team builds a product on an open source agent and sells it. The team is the provider of that product. If the product's intended purpose sits in Annex III, the team carries the full Chapter III obligations, including the Article 43 conformity assessment, the Annex IV documentation and the Article 72 post-market monitoring plan.

A customer deploys that product and lets it learn. Article 25(1)(b) is the key: a deployer becomes a provider if "they make a substantial modification to a high-risk AI system that has already been placed on the market or has already been put into service in such a way that it remains a high-risk AI system". Learning that stays within the original provider's pre-determined envelope is not a substantial modification. Customer-side changes outside it may be, which shifts obligations to the customer. Article 25(1)(c) adds that changing the intended purpose of a non-high-risk system, "including a general-purpose AI system", so that it becomes high-risk also makes you the provider.

A team fine-tunes the model. That changes the GPAI model itself. The Commission's GPAI guidelines say only those making significant modifications take on GPAI provider obligations; check the thresholds there.

What about GPAI model obligations?

Article 53 obliges GPAI model providers to keep technical documentation, inform downstream providers, maintain a copyright policy and publish a training content summary. The Commission's GPAI page says these obligations "entered into application on 2 August 2025". The guidelines also explain the conditions under which open-source model providers are exempt from some of those obligations.

For a team deploying an agent, the useful part is Article 53(1)(b): the model provider must give you information that enables you "to have a good understanding of the capabilities and limitations" of the model. Keep it with your agent records, so that when behaviour changes you can show whether the cause was the model, the harness release or the learned artifacts.

Which dates apply now, and has anything been postponed?

Yes, the high-risk dates have moved. Article 113 of the original Regulation set general application from 2 August 2026, with Article 6(1) obligations from 2 August 2027. The Commission's proposal for an "AI Omnibus" under its digital simplification package changed that. As of 23 October 2026, the Commission's regulatory framework page (last updated 19 October 2026) says the Omnibus reached political agreement on 7 May 2026 and entered into force on 27 July 2026, and it links the Official Journal reference L 2026/1744.

The EU's transition pathways page (published 26 August 2026) adds that AI embedded in machinery "will no longer sit under the AI Act's separate high-risk regime", with AI-specific safety requirements moving to delegated acts under the Machinery Regulation.

Two cautions. The postponement moves the deadline, not the design work: a learning system's pre-determined change envelope has to exist before its conformity assessment. And Article 50 transparency and Article 4 literacy already apply. Our EU AI Act high-risk obligations guide covers the full Chapter III list.

How NIST AI RMF 1.0 applies to an agent whose behaviour changes

NIST released AI RMF 1.0 (NIST AI 100-1) on 26 January 2023. It is voluntary, and NIST's AI RMF page notes it "is being revised as part of the White House AI Action Plan". The current text still fits learning systems well, because NIST wrote change into its premises. Section 1 notes that AI systems "may be trained on data that can change over time, sometimes significantly and unexpectedly", and that some risks "may be latent at a given point in time and may increase as AI systems adapt and evolve."

GOVERN: decide who may change the agent, and how

• GOVERN 1.5 asks for "ongoing monitoring and periodic review of the risk management process", with roles and the review frequency defined. For a learning agent, set a review cadence for the skill library and memory, not only for the model.
• GOVERN 1.6 asks for "mechanisms ... to inventory AI systems". Your inventory entry for an agent should name the harness and version, the model and provider, the tool set, the intended purpose, and the location of every learned artifact store.
• GOVERN 1.7 covers decommissioning safely. Learned skills and memory may hold internal procedures and personal data; retirement needs a plan for them.
• GOVERN 6.1 and 6.2 cover third-party risk and "contingency processes ... to handle failures or incidents in third-party data or AI systems". The harness, the model, MCP servers and hub-installed skills are all third-party components.

MAP: describe the system as it will be, not as it shipped

• MAP 3.5 asks that "processes for human oversight are defined, assessed, and documented". Decide which self-modifications need a human: skill creation, skill deletion, memory writes, tool additions.
• MAP 4.1 asks for approaches to map the technology and legal risks of the system's components, including third-party data or software. Treat each skill as a component: bundled, hub-installed and agent-written skills carry different risk.

MEASURE: watch behaviour in production, not only before release

• MEASURE 2.4: "The functionality and behavior of the AI system and its components ... are monitored when in production." For an agent, "components" includes skills. Track which skills load, how often, and what they changed.
• MEASURE 2.7: "AI system security and resilience ... are evaluated and documented." Include persistence attacks through memory and skills in the evaluation scope.
• MEASURE 3.1 asks for "approaches, personnel, and documentation ... to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts." Emergent behaviour is the expected case for a self-improving agent, so this subcategory needs a real owner.

MANAGE: be able to stop it and put it back

• MANAGE 2.4: "Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use." For a learning agent this means rollback of learned state, not just shutdown.
• MANAGE 4.1 asks for post-deployment monitoring plans including "appeal and override, decommissioning, incident response, recovery, and change management." Change management is the heart of governing a system that changes itself.
• MANAGE 4.3 asks that incidents and errors are communicated and that "processes for tracking, responding to, and recovering from incidents and errors are followed and documented."

The AI RMF Playbook on NIST's AI Resource Center gives suggested actions for each subcategory. NIST is clear that it "is neither a checklist nor set of steps to be followed in its entirety" and that its suggestions are voluntary. Our 12-week AI RMF implementation calendar turns the four functions into a schedule.

What the Generative AI Profile (NIST AI 600-1) adds

NIST released AI 600-1, the Generative AI Profile, on 26 July 2024. It names twelve risks that are unique to or made worse by generative AI and attaches suggested actions to AI RMF subcategories. Three of the twelve matter most for self-improving agents.

Information Integrity. The profile describes content that "may not distinguish fact from opinion or fiction". A self-improving agent turns its own outputs into instructions, so a confabulated fact saved to memory comes back as trusted context. Confabulation is the source; the learning loop is the amplifier.

Information Security. The profile notes that generative AI "expands the available attack surface, as GAI itself is vulnerable to attacks like prompt injection or data poisoning." An agent that saves what it learns from web pages, issues or emails creates a path from untrusted input to persistent instructions.

Value Chain and Component Integration. The profile defines this as "non-transparent or untraceable integration of upstream third-party components". An agent's value chain includes the model, the harness, MCP servers, community skills and, uniquely, components the agent writes for itself. Section 2.12 notes that with many third-party components "it may be difficult to attribute issues in a system's behavior to any one of these sources." Versioning each learned artifact is how you keep attribution possible.

Several of the profile's suggested actions translate directly:

Our explainer on the twelve NIST AI 600-1 risks covers the rest.

What records, oversight and monitoring should a team keep?

Logs

Article 12(1) requires that high-risk AI systems "technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 12(2)(a) asks that logs enable identifying situations that may result in a risk "or in a substantial modification." For a learning agent that second clause is the important one: your logs must let you see when the agent changed itself.

Article 26(6) requires deployers to keep automatically generated logs under their control "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months", subject to other Union or national law. Article 19 sets the equivalent duty for providers.

For an agent, the minimum useful log set is:

• every tool call, with arguments and result status;
• every write to a learned artifact (memory entry, skill create, patch, delete, supporting file), with the before and after content or a diff;
• which skills and memory snapshot were loaded for each session;
• every approval decision, who made it and when;
• the model and harness version in use for each session.

Hermes writes local logs under ~/.hermes/logs/ and sessions to ~/.hermes/state.db, both on a host the agent can reach. Ship copies of anything that may become evidence to storage the agent cannot write. Our post on audit log fields for agent tool calls lists fields worth capturing.

A change register for skills and memory

Neither framework says "change register", but Article 12(2)(a), Annex IV point 2(f) and MANAGE 4.1 all need what it provides. For each change to a learned artifact, record:

Git is the cheapest way to get most of this for free, and the walkthrough below sets it up.

Human oversight

Article 14(4) lists what overseers must be enabled to do, including "(a) to properly understand the relevant capacities and limitations", "(b) to remain aware of the possible tendency of automatically relying or over-relying on the output" (automation bias), "(d) to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output", and "(e) to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure".

For a self-improving agent, "reverse the output" has to include reversing what it learned. Approval gates that stage writes, and a versioned store that supports rollback, make points (d) and (e) real.

Watch for automation bias in the review step itself. Hermes's default "smart" approvals mode uses an auxiliary LLM to judge command risk; convenient for interactive use, but an LLM approving another LLM's actions is not the human oversight Article 14 describes.

Post-market monitoring

Article 72(1) requires providers to "establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks". Article 72(2) asks that it "actively and systematically collect, document and analyse relevant data ... on the performance of high-risk AI systems throughout their lifetime", and adds that "where relevant, post-market monitoring shall include an analysis of the interaction with other AI systems."

That last clause fits agents that call MCP servers, delegate to subagents or route review passes to auxiliary models. Under Article 26(5), deployers must monitor operation, inform providers and suspend use where they see a risk. Our post-market monitoring guide covers the plan template in detail.

Control mapping: mechanism, risk, article, subcategory, control

Step by step: setting up the controls

The walkthrough uses Hermes Agent because its configuration keys are documented. Keys and defaults below were read from the Hermes docs in the repository on 23 October 2026 (website/docs/user-guide/configuration.md, security.md, features/skills.md, features/memory.md, features/curator.md). Hermes ships several releases a week, so re-read those pages for the version you run. The same steps translate to any agent with a writable memory or skill store.

Step 1: write down the intended purpose and the change envelope

Before touching configuration, write a one-page record. It is the anchor for Article 3(23), Article 6(4), Annex IV point 2(f) and GOVERN 1.6.

# agent-record.yaml (keep in the governance repo, not on the agent host)
system: eng-assistant-prod
harness: hermes-agent
harness_version: v0.22.5          # record what you actually run
model:
  provider: your-provider
  model: your-pinned-model
intended_purpose: >
  Assist the platform team with build failures, dependency upgrades and
  internal runbooks. Not used for decisions about people.
annex_iii_assessment: not-in-scope (documented 2026-10-23, owner: risk lead)
learned_artifacts:
  memory: ~/.hermes/memories/
  skills: ~/.hermes/skills/
  sessions: ~/.hermes/state.db
pre_determined_changes:
  - memory notes about environment facts and conventions, max 2,200 chars
  - new or patched skills for tasks inside the intended purpose, after review
  - curator archival of unused agent-created skills (no consolidation)
outside_envelope:
  - any skill touching HR, credit, education or other Annex III areas
  - removal of approval or verification steps from any skill
  - model or provider change without re-evaluation
oversight_owner: platform-lead
stop_procedure: runbooks/agent-stop.md

Step 2: gate learned writes and command execution

Add the following to ~/.hermes/config.yaml. Every key here appears in the Hermes docs; the values are a stricter posture than the defaults.

memory:
  write_approval: true        # default false. true stages writes for review outside the interactive CLI

skills:
  write_approval: true        # default false. true stages every skill_manage write under ~/.hermes/pending/skills/
  guard_agent_created: true   # default false. content scanner for dangerous patterns, independent of approval

curator:
  enabled: true
  consolidate: false          # default false. keep the LLM consolidation pass off unless reviewed
  prune_builtins: false

approvals:
  mode: manual                # default smart (an auxiliary LLM judges risk). manual prompts a person
  deny:
    - "git push --force*"     # glob patterns blocked even under yolo or mode: off

updates:
  pre_update_backup: full     # default quick. full also zips HERMES_HOME before updates
  backup_keep: 5

Review staged changes with the commands the docs list:

/skills pending
/skills diff <id>
/skills approve <id>
/skills reject <id>
/memory pending
/memory approve <id>
/memory reject <id>

Per the docs, with memory.write_approval: true interactive CLI writes prompt inline while gateway, script and background review writes are staged. skills.guard_agent_created is a heuristic scanner the docs say was turned off by default because legitimate workflows tripped it, so treat it as a second layer, not a replacement for review. approvals.mode: manual costs convenience; if you keep smart for low-risk interactive use, document that an auxiliary model makes the first call.

Step 3: put learned artifacts under version control

Warning: the commands below change files in the agent's home directory. Stop the agent and any gateway first, then take a backup.

Back up first:

# stop the agent and gateway before you begin, then:
tar -czf ~/hermes-backup-$(date +%Y%m%d-%H%M%S).tar.gz -C ~ .hermes
ls -lh ~/hermes-backup-*.tar.gz

Then create a repository that tracks only the learned artifacts. Do not track .env or auth files, and do not commit state.db (it is large, changes constantly and can hold sensitive conversation content; export what you need to your log store instead).

cd ~/.hermes
git init
cat > .gitignore <<'EOF'
*
!.gitignore
!memories/
!memories/**
!skills/
!skills/**
!config.yaml
EOF
git add -A
git commit -m "baseline: learned artifacts at harness v0.22.5"
git tag baseline-2026-10-23

Commit on a schedule so every change lands in history with a timestamp, even if someone forgets:

# crontab -e  (every 15 minutes)
*/15 * * * * cd "$HOME/.hermes" && git add -A && git diff --cached --quiet || git commit -q -m "auto: learned state $(date -u +%Y-%m-%dT%H:%MZ)"

The git history of the skills and memories directories is now your change register's raw data. Add the register fields from the table above as commit trailers when a human approves a change:

git commit -m "skill: patch build-failure-triage" \
  -m "Origin: background-review" \
  -m "Envelope: inside" \
  -m "Reviewer: platform-lead" \
  -m "Tests: skill-regression passed"

Step 4: pin safety-relevant skills

The curator docs say pinned skills are skipped by automated archival and that the agent's skill_manage tool refuses to delete them, while patches still go through. Pin skills that encode a safeguard, such as a verification procedure, then rely on review to catch edits:

hermes curator pin release-verification
hermes curator status

Preview what the curator would do before it runs:

hermes curator run --dry-run

Step 5: sign snapshots so you can prove what the agent knew

When you approve a batch of changes, produce a signed snapshot of the learned state. This gives you evidence of what the skill library and memory contained at a point in time, which supports Article 12 traceability and GV-1.6-003 provenance.

cd ~/.hermes
SNAP=learned-state-$(git rev-parse --short HEAD).tar.gz
git archive --format=tar.gz -o ~/"$SNAP" HEAD
sha256sum ~/"$SNAP" | tee ~/"$SNAP".sha256

# keyless signing with Sigstore cosign (requires an OIDC identity)
cosign sign-blob --bundle ~/"$SNAP".sigstore.json ~/"$SNAP"

# later, verify against the identity that signed it
cosign verify-blob --bundle ~/"$SNAP".sigstore.json \
  --certificate-identity platform-lead@example.com \
  --certificate-oidc-issuer https://oidc.example.com \
  ~/"$SNAP"

Store the snapshot, digest and bundle outside the agent host.

Step 6: generate an SBOM for the agent's own environment

The harness, its Python dependencies, MCP servers and any packages the agent installed are software components that receive CVEs. Hermes itself has had two CVE records published on 3 September 2026 (CVE-2026-71963 and CVE-2026-85105). An SBOM of the agent environment is how you answer "are we running an affected version" in minutes.

python3 -m pip install cyclonedx-bom
# point at the Python environment Hermes runs in
cyclonedx-py environment --of JSON -o hermes-env.cdx.json /path/to/hermes/venv

# record the harness version alongside it if your install is a git checkout
git -C /path/to/hermes-agent describe --tags

Keep the SBOM with the agent-record.yaml from step 1. Regenerate it after every update.

Step 7: put skill changes through code review in CI

For teams that share skills across agents, keep the approved skill library in a repository and distribute it from there. Pull requests then become the review gate, and GitHub's code owners feature names the reviewer.

# .github/CODEOWNERS
/skills/   @your-org/agent-governance

# .github/workflows/skill-review.yml
name: skill-review
on:
  pull_request:
    paths: ["skills/**"]
jobs:
  check:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: List changed skills
        run: git diff --name-status origin/${{ github.base_ref }}...HEAD -- skills/
      - name: Flag removed safeguards
        run: |
          # fail if a diff deletes lines mentioning approval or verification
          if git diff origin/${{ github.base_ref }}...HEAD -- skills/ \
             | grep -E '^-.*(Verification|approve|approval|confirm)' ; then
            echo "A change removes a verification or approval step. Needs explicit sign-off."
            exit 1
          fi
      - name: Hash approved skills
        run: find skills -type f -print0 | sort -z | xargs -0 sha256sum > skills.sha256
      - uses: actions/upload-artifact@v4
        with:
          name: skills-manifest
          path: skills.sha256

Require code owner review on the default branch. The grep check is deliberately simple; adapt it to your skills' section names (Hermes skills commonly include a Verification section).

Step 8: monitoring and retention

• Ship ~/.hermes/logs/ and an export of session metadata to a store the agent cannot write, and keep it at least six months if you may be a deployer of a high-risk system (Article 26(6)).
• Alert on writes outside the envelope: a new skill whose name or content matches an out-of-scope area, any deletion, any change to config.yaml.
• Review the change register weekly (GOVERN 1.5) and record the review.
• Track two numbers for MS-2.7-006: time from a bad learned change to its detection, and time from detection to rollback.

Step 9: the stop button and rollback

Article 14(4)(e) and MANAGE 2.4 need a procedure, not just an intention. Write it down and test it.

Warning: rolling back discards learned state newer than the target commit. Stop the agent and gateway first, take a fresh backup, and confirm the target commit before you run anything.

# 1. stop the agent and gateway, then back up the current state
tar -czf ~/hermes-pre-rollback-$(date +%Y%m%d-%H%M%S).tar.gz -C ~ .hermes

# 2. inspect history and pick the last known good commit
cd ~/.hermes
git log --oneline -- skills/ memories/ | head -20
git diff baseline-2026-10-23 -- skills/ memories/ | less

# 3. restore only the learned directories to that commit
git checkout baseline-2026-10-23 -- skills/ memories/
git commit -m "rollback: learned state to baseline-2026-10-23" -m "Reason: INCIDENT-123"

Restoring only the learned directories as a new commit keeps history intact and avoids a hard reset, which would discard the record of what happened. The incident commit is part of your evidence. If the agent learned the bad behaviour from an input it will see again, fix that input before restarting, or it may relearn it.

How do ISO/IEC 42001 and the OWASP agentic guidance fit alongside?

ISO/IEC 42001:2023 specifies requirements for an AI management system. It uses the same management system structure as other ISO standards, with an Annex A set of controls, and it is certifiable. The ISO site blocked our scripted fetch on 23 October 2026, so we cite its catalogue page as a reference rather than quoting it; ISO's own summary notes that features such as continuous learning may call for additional safeguards. In practice, 42001 is the organisational wrapper (policy, roles, risk and impact assessment, suppliers, monitoring, improvement). NIST AI RMF work produces much of the evidence a 42001 audit expects, and it overlaps with the Article 17 quality management system for high-risk providers. Certification is voluntary and does not replace the Act's legal obligations.

OWASP Top 10 for Agentic Applications for 2026, published by the OWASP GenAI Security Project on 9 December 2025, is the threat catalogue to pair with the governance frameworks. Four entries map directly to self-improving agents:

Use OWASP to scope red-team exercises (MS-2.7-007) and threat models, NIST to structure the programme, 42001 to run it as a management system, and the AI Act to decide what is legally required. Our comparison of the OWASP LLM and agentic lists helps decide which to map against.

Where Safeguard fits, and where it does not

Safeguard does not govern, scan or monitor Hermes Agent, and Hermes is not a Safeguard integration or partner. Nothing in Safeguard decides whether your agent is high-risk or writes your conformity assessment.

Where it helps is the software supply chain side of the controls above. An agent that writes code, installs packages and authors skill scripts produces artifacts that end up in your repositories and images. Safeguard generates and analyses SBOMs in SPDX and CycloneDX, matches components against vulnerability data, and evaluates policies and gates in CI, so a dependency the agent added goes through the same checks as one a person added. Attestation and signing support (SLSA, Sigstore, in-toto) covers provenance for what you build. Agent identity tracks which agent holds what access. The compliance suite's framework catalogue includes the EU AI Act, NIST AI RMF and ISO/IEC 42001 for evidence mapping. AI-BOM discovery, which inventories AI assets across code and cloud, is in early access, as are MCP Guardrail and the AI Gateway.

Common mistakes

• Treating "it learns" as the high-risk trigger. It is not. Use decides. Equally, "it is just a coding agent" is not a defence once the learned skill library drifts into an Annex III task.
• Documenting the model and ignoring the learned artifacts. For agents that keep weights fixed, the skill library and memory are where behaviour changes. An inventory that lists only the model misses the part that moves.
• Leaving write gates at their defaults in unattended deployments. In Hermes, memory.write_approval and skills.write_approval both default to false. That suits a personal assistant. It does not suit a shared or high-risk deployment.
• Counting an LLM approval as human oversight. An auxiliary model judging risk is a useful filter. Article 14 asks for natural persons who can understand, override and stop the system.
• Keeping logs only on the agent host. If the agent can write to the log store, the logs are weaker evidence. Ship them elsewhere.
• Rolling back with a hard reset, or without fixing the source. A hard reset erases the incident record; restore directories as a new commit. And if a poisoned document taught the agent a bad procedure, it will relearn it from that document.
• Assuming the open source licence exempts your deployment. Article 2(12) protects the release, not your high-risk use or your Article 50 duties.
• Reading the postponement as a reprieve on design, or quoting stale dates. Pre-determined change envelopes must exist before conformity assessment, and several secondary sources still show the pre-Omnibus timeline.

FAQ

Is a self-improving AI agent high-risk under the EU AI Act?

Not automatically. It is an AI system under Article 3(1), and high-risk only if its use falls under Annex III (for example recruitment or education) or it is a safety component of an Annex I product. Profiling of natural persons in an Annex III area always makes it high-risk.

Does an agent that learns after deployment need a new conformity assessment every time it changes?

No, if the changes were pre-determined by the provider at the initial conformity assessment and described in the technical documentation under Annex IV point 2(f). Article 43(4) says those changes are not a substantial modification. Changes that were not foreseen and affect compliance or the intended purpose are, and trigger a new assessment.

Who is the provider when we run an open source agent with a third-party model?

The model developer is the GPAI model provider. The open source project is generally outside the Act under Article 2(12) unless it is placed on the market as a high-risk system or under Articles 5 or 50. Your organisation is the provider of the configured agent if you put it into service under your name for a high-risk purpose, and its deployer if you use it.

When do the EU AI Act high-risk obligations apply now?

According to the Commission's AI Act page updated 19 October 2026, Annex III high-risk obligations apply from 2 December 2027 and Annex I product obligations from 2 August 2028, after the AI Omnibus entered into force on 27 July 2026. GPAI obligations have applied since 2 August 2025.

What does NIST AI 600-1 add for agents?

It names twelve generative AI risks and attaches suggested actions to AI RMF subcategories. For self-improving agents, Information Integrity, Information Security and Value Chain and Component Integration matter most, and actions such as GV-1.6-003 (provenance in inventory) and MS-2.7-006 (how fast the system adapts after incidents) apply directly.

How long should we keep agent logs?

If you are a deployer of a high-risk system, Article 26(6) sets a floor of at least six months for logs under your control, subject to other Union or national law such as data protection rules. For other agents, keep them long enough to reconstruct any decision you may be asked about.

Is Hermes Agent safe to run in a regulated environment?

That depends on configuration and use. Its docs describe container backends, approval modes, deny rules, write approval gates and a content scanner, several off or permissive by default. Pin a version, tighten the gates, version the learned state and keep logs off-host; your organisation carries the obligations for how you deploy it.

What is the difference between Hermes Agent and the Hermes models?

Hermes Agent is Nous Research's open source agent harness, which can run on many model providers. The Hermes models are Nous Research's open-weight fine-tuned language models. Under the AI Act they sit at different layers: a model is a candidate GPAI model; the agent you configure and deploy is an AI system.

Fix it without waiting for upstream

A self-improving agent installs packages and writes scripts that become part of your codebase, and the agent's own dependency tree, plugins and skill scripts are open source components that receive CVEs like any other. Governance frameworks ask you to manage those third-party components (GOVERN 6.1, MANAGE 3.1, Article 15(5)), and in practice that means getting fixed versions into production quickly.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude connected to the Safeguard MCP server, installed from Claude's connector directory with OAuth, and how you choose which Safeguard tools Claude may use. Choosing tools per assistant is the same least-privilege decision this guide asks you to make for any agent: write down which tools it may call, and grant only those.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: it is asked to fix a lodash CVE, reads the finding and advisory, asks before each command, edits package.json, runs install and tests with approval, prints a summary and pushes nothing. That approve-each-step pattern is the human oversight shape Article 14 describes, applied to an agent changing your code.

Click through it at your own pace, or open it full screen.

The third demo sets up the Safeguard runner on your own machine, approves it with a device code, and scans from the terminal. Running scans locally is how you would produce an SBOM and findings for the environment an agent runs in without sending that environment anywhere first.

Click through it at your own pace, or open it full screen.

To try it yourself, download Safeguard and read the CLI documentation.

Quick check

Sources

• Regulation (EU) 2024/1689 (AI Act), Official Journal text via the EU Publications Office
• European Commission, AI Act regulatory framework page (updated 19 October 2026)
• European Commission, guidelines for providers of general-purpose AI models
• European Commission, guidelines on the AI system definition (6 February 2025)
• EU transition pathways, AI Act Digital Omnibus: high-risk deadlines postponed
• NIST AI 100-1, AI Risk Management Framework 1.0
• NIST AI 600-1, Generative AI Profile
• NIST AI Risk Management Framework page
• NIST AI RMF Playbook, AI Resource Center
• ISO/IEC 42001:2023 catalogue page
• OWASP Top 10 for Agentic Applications for 2026
• OWASP GenAI Security Project, announcement of the Agentic Top 10 (9 December 2025)
• OWASP Agentic Security Initiative
• Hermes Agent repository, Nous Research
• Hermes Agent release feed
• Hermes Agent docs: skills
• Hermes Agent docs: memory
• Hermes Agent docs: curator
• Hermes Agent docs: configuration
• Hermes Agent docs: security

Last reviewed: 24 October 2026. Hermes Agent ships several releases a week and the AI Act timeline has already changed once; check the linked sources for the latest status.