TL;DR: Hermes shows how an open agent harness can move beyond a simple model loop by treating sessions as infrastructure, separating tool registration from tool exposure, and preserving lineage during compression, according to Arize. The architectural lesson is that durable agent systems need explicit runtime boundaries, not just better prompts or larger context windows.
At a glance
What this is: Hermes is an open-source agent harness that emphasizes session infrastructure, scoped tool exposure, and lineage-aware compression for long-running agent systems.
Why it matters: It matters to identity and security teams because agent harness design shapes how tools, permissions, and persistence are governed when AI systems operate for extended periods.
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, meaning organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.
👉 Read Arize's analysis of Hermes agent harness architecture
Context
Hermes is a good example of why agent harness architecture now matters as much as model choice. The security issue is not whether an agent can call tools, but how runtime boundaries are defined around sessions, tool exposure, delegation, and persistence in environments where AI systems can act for long periods.
For IAM and PAM teams, the relevance is direct: long-running agents behave like non-human identities with state, scope, and lifecycle. The article's core point is that governance has to move from static prompt control toward session-scoped access, bounded delegation, and auditable lineage, which is a typical gap in early agent deployments.
Hermes is also atypical in how explicitly it surfaces infrastructure-like session handling, but the broader direction is becoming common across agent systems. That makes it a useful reference point for security architects deciding where identity controls belong in the stack.
Key questions
Q: How should security teams govern AI agents that can remember user interactions across sessions?
A: Treat persistent memory as part of the security boundary, not as optional context. Separate user-editable memory from system policy, validate any durable state before reuse, and assume a low-privilege user may try to shape future agent behaviour through repeated interactions. If memory can alter trust, it needs lifecycle controls and review.
Q: Why do AI agents complicate least privilege controls?
A: AI agents complicate least privilege because they do not stop at an access boundary the way a person might. If they are optimising for task completion and have a path to request or create more access, they may expand their own privileges. Least privilege still matters, but only when paired with hard limits on escalation and identity creation.
Q: What breaks when tool exposure is not separated from tool registration?
A: The model can inherit visibility into capabilities that were only meant to exist in the backend, which increases misuse risk and makes policy enforcement harder. Separation lets teams keep a rich integration library while showing the model only the narrow toolset needed for the current run. Without that split, governance becomes brittle and noisy.
Q: How do teams know whether AI session compression is safe for governance?
A: Compression is safe only when the system preserves enough provenance to explain what changed and why. Teams should look for parent-child lineage, summarisation metadata, and the ability to reconstruct earlier context states. If compression produces a single rewritten transcript with no history, governance and forensics both lose critical evidence.
Technical breakdown
Agent harness loop and provider abstraction
Hermes uses the standard agent loop of model call, tool dispatch, tool result append, and repeat, but normalises multiple provider surfaces through transport adapters. That means the runtime can present a consistent tool-calling model even when the upstream APIs differ, which reduces integration friction and keeps orchestration logic separate from model-specific quirks. This is not just a developer convenience. In agent systems, provider abstraction also creates a control point where policy, logging, and routing can be inserted before the model sees tools or context.
Practical implication: centralise provider adapters so access policy and telemetry are enforced before tool invocation.
Session lifecycle, compression, and lineage
Hermes treats compression as a lifecycle event rather than a simple truncation step. Older turns are summarised, head and tail context are preserved, and the system creates a child session with a new ID and parent-child lineage when compression occurs. That design preserves traceability across long conversations and avoids rewriting history into a single mutable transcript. From a governance perspective, lineage is valuable because it lets teams reason about what the agent knew at each stage and how context was transformed over time.
Practical implication: preserve session lineage and audit trails when compressing agent context so behaviour remains explainable.
Tool registration versus tool exposure
Hermes separates the full registered tool inventory from the smaller set exposed to a specific run. Tools can exist in the registry without being visible to the model, and that exposed set can be narrowed again by profile or delegation context. This distinction matters because the attack surface is not the total number of available integrations, but the number the model can actually invoke in a given session. For security teams, this is the architectural equivalent of scoping credentials and entitlements to the minimum runtime boundary.
Practical implication: restrict model-visible tools per session or profile instead of exposing the full integration catalog.
NHI Mgmt Group analysis
Session-scoped agent governance is becoming the right unit of control. Hermes shows that long-running agents are not well described by a single prompt or a single execution. They need sessions, lifecycle transitions, and scoped runtime state. That aligns with how identity teams already think about non-human identities: control the session, not just the account. Practitioner conclusion: treat agent sessions as governed identities with explicit start, boundary, and end states.
Tool exposure is more important than tool inventory. The article makes a useful distinction between registering tools and exposing them to the model. That is a better security model than assuming everything installed is equally reachable. In practice, this mirrors least privilege for NHI systems and reduces the chance that an agent can discover or misuse capabilities it should never see. Practitioner conclusion: design for model-visible minimisation, not just backend availability.
Lineage-aware compression is a strong pattern for agent accountability. When context is rewritten without lineage, teams lose the ability to reconstruct why the agent acted. Hermes preserves parent-child relationships across compression, which is a useful governance primitive for autonomous and semi-autonomous systems. The named concept here is context lineage control: preserving the provenance of summarised agent state so decisions remain traceable across long sessions. Practitioner conclusion: require provenance metadata whenever context is compressed or rolled forward.
Durable orchestration is the next control gap, not better delegation syntax. Hermes already supports useful child runs, but the article is clear that durable, externally steerable child-run control is still emerging. That gap matters because unmanaged subagents can become shadow AI workload paths with unclear ownership and cleanup semantics. Practitioner conclusion: do not mistake delegation for governance until sub-run lifecycle, ownership, and termination are explicitly controlled.
This architecture confirms that NHI governance must extend into AI runtimes. The article is not about identity in the narrow IAM sense, but it exposes the same control problem that appears in service accounts and workload identities: what can act, what can it reach, and how long does that access persist. That makes OWASP-NHI and agentic AI controls directly relevant to harness design. Practitioner conclusion: fold agent runtimes into identity governance, not just application engineering.
What this signals
Context lineage control: agent systems that compress or rewrite memory need provenance metadata, otherwise investigations cannot distinguish a true decision from a summarisation artefact. For teams aligning to the NIST AI Risk Management Framework, the operational question is whether the runtime can explain its own state transitions.
Hermes also reinforces a broader programme signal for identity teams: AI agents are now part of the non-human estate, which means access scope, delegation, and termination must be handled like other governed identities. The gap is no longer conceptual, it is operational and visible in how harnesses are being built.
Where this gets real is tool exposure. If the runtime can register many tools but expose only a narrow set to the model, security teams have a practical path to reduce blast radius without breaking developer velocity. That is the same logic that drives least privilege elsewhere in identity architecture.
For practitioners
- Define sessions as governed identity boundaries Assign ownership, start conditions, and termination criteria to each long-running agent session so context, tools, and outputs are tied to a controllable lifecycle boundary.
- Scope model-visible tools per run Keep the installed tool library broad if needed, but expose only the minimum tools required for the current task, profile, or delegated sub-run.
- Preserve compression lineage and audit metadata Record parent-child session relationships, summarisation events, and the reason a context boundary moved so investigators can reconstruct agent behaviour later.
- Apply least privilege to AI agents and their tool surfaces Map agent access to the same principle used for other non-human identities, including explicit scoping for credentials, connectors, and high-risk actions.
Key takeaways
- Hermes is notable because it treats agent sessions as infrastructure, which is the right mental model for long-running AI systems.
- The strongest architectural lesson is the split between tool registration and tool exposure, which maps directly to least-privilege governance for non-human identities.
- Lineage-aware compression improves traceability, but durable child-run orchestration remains the next governance gap for production agent systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | The article maps to agent tool misuse, delegation, and runtime boundary risks. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Long-running agents behave like non-human identities with scoped access and lifecycle. |
| NIST AI RMF | GOVERN | Agent lifecycle ownership and accountability are central to this architecture. |
| NIST Zero Trust (SP 800-207) | Scoped runtime exposure mirrors zero trust principles for tools and sessions. | |
| NIST CSF 2.0 | PR.AC-4 | The article is fundamentally about access scope and permission minimisation. |
Apply zero trust principles to every session and tool invocation rather than trusting the harness.
Key terms
- Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
- Tool Exposure: Tool exposure is the subset of available capabilities that a model can actually see and invoke during a specific run. It is a security boundary, not just an engineering convenience, because limiting exposure reduces misuse and shrinks the effective attack surface.
- Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
- Session Lifecycle: Session lifecycle is the sequence of state changes that begins when a user authenticates and ends when access is revoked or expires. It includes renewal, refresh, revocation, and timeout behaviour, and weak handling at any step can turn a working login flow into a security defect.
What's in the full article
Arize's full blog covers the implementation detail this post intentionally leaves for the source:
- Provider adapter behaviour across Anthropic Messages, Codex Responses, Bedrock, and other runtime surfaces
- Session storage, FTS5 search, WAL journaling, and fallback behaviour for persistence and recovery
- Lifecycle hook execution points for policy enforcement, auditing, and host-side effects
- Profile isolation and cron handling details that show how unattended agent runs are governed in practice
👉 The full Arize post covers session lifecycle, delegation limits, and prompt assembly details
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security for practitioners building controlled runtime access. It helps identity and security teams apply lifecycle thinking to AI systems, service accounts, and other non-human identities.
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org