TL;DR
- Hermes Agent from Nous Research is one of the most popular self-improving AI agents.
- Autonomous agents like Hermes typically have your credentials in their environment and unrestricted outbound network access.
- Securing an AI agent comes down to five areas: identity, networking, credential isolation, runtime containment, and audit.
- In this post, you'll learn how to secure your Hermes Agent from scratch, and how Lens Agents gives you that governance out of the box.
Hermes Agent from Nous Research is an autonomous AI agent that keeps state, works goals over time, talks to you through Slack, Telegram, WhatsApp, or Discord, and runs continuously.
That makes it really powerful, but an agent that never sleeps and can use several different tools is an agent that needs real boundaries.
Prefer to watch instead:
Why Autonomous AI Agents Raise Security Concerns
Coding assistants and chatbots mostly act when you ask them to do something. Autonomous agents are a different category, because they monitor, decide, and act on their own schedules. Hermes Agent can watch a Slack channel, pick up a task, run tools, and report back hours later with no human in the loop.
None of that is a flaw, and it applies to any autonomous agent you run directly on a host.
The default deployment pattern for an AI agent looks like this:
- Credentials live in the agent's environment: API keys, tokens, kubeconfig, and cloud credentials typically sit in config files or environment variables, where the agent (and anything that compromises it) can read them.
- The network is open: The agent can call any endpoint on the internet. If it gets prompt-injected into exfiltrating data, nothing stops the outbound request from reaching the attacker who wants that data.
- The host gets inherited: The agent can read the host's filesystem, install packages on it, and reach the internal network.
- There's no audit trail: You won't know what the agent has done, and you won't have any history of when something changed or why.
- It's always on: Always-on is a powerful feature for an autonomous agent, but without guardrails it also means a window of exposure that never closes.
All of that is manageable for a personal project. Point it at real production data and the risks become real, which is why most enterprises either ban autonomous agents or end up running them ungoverned as shadow IT. Neither is a good outcome, so let's fix the deployment model.
What Does Secure Mean for an AI Agent?
To be secure, an AI agent needs:
- Its own identity: The agent should act as itself, not be mistaken for the user who owns it. Every action should be attributable to the agent, with its own permissions.
- Least privilege and default-deny: The agent should access only the systems it needs, and nothing else.
- Credential scoping: Secrets held by the agent should be narrow, short-lived, and revocable. Ideally, they shouldn't be held by the agent at all.
- Runtime containment: The agent process should be isolated from the host and always run as an unprivileged user, so a compromised agent doesn't become a compromised host.
- Audit: You should know exactly what the agent is doing — what commands it runs, which tools it uses, which API calls and network requests it makes, and which model it used.
Now that we know what we need, let's look at how to get there with Hermes.
How to Harden a Self-Hosted Hermes Agent
This is a step-by-step guide to the decisions you need to make to harden Hermes Agent in your environment.
Step 1: Contain the runtime
First, make sure your agent doesn't run directly on your host, and doesn't run as root. Most people run Hermes in a container as an unprivileged user, with all Linux capabilities dropped and privilege escalation disabled.
That's a good starting point, but you can do better. If you want stronger isolation than a shared kernel, run this setup in a microVM. A microVM strips a VM down to its essentials, boots in seconds, and gives you a hardware-level boundary, which makes it a better fit than containers for this type of workflow.
Learn more about why microVMs win for agentic AI workflows.
Step 2: Control the egress
The worst outcome of prompt injection is exfiltration. When you control egress, the agent can only reach an explicit allowlist of destinations, and everything else is refused.
You can point Hermes at a proxy through an environment variable, then block direct egress from the agent's network with firewall rules. When prompt injection happens, it fails at the network layer and the attempt lands in your proxy logs.
Step 3: Give your Hermes Agent its own identity
Think about Kubernetes for a second. If your agent has access to your kubeconfig, the agent effectively is you (with cluster-admin privileges on a bad day), and every action it takes is attributed to your name in the audit log.
Create a dedicated ServiceAccount for the agent instead, and scope role-based access control (RBAC) to exactly what the agent needs to do.
Apply the same principle everywhere else the agent touches: your version control system, your cloud account, and any other system it reaches.
Step 4: Keep credentials short-lived
Long-lived static credentials are a nightmare in non-agentic workflows. Add AI to the equation and they become a catastrophe. Scoping and short lifetimes shrink the blast radius, but they don't eliminate it.
For true credential isolation, the agent must never see a usable secret. That means a boundary between the agent and the credential, which is hard to build yourself — we'll cover something that helps with that later in the article.
Step 5: Build an audit trail
You need to answer who did what, and when. Build that from logs, not from the agent's memory. Use proxy access logs, the Kubernetes API server's audit logs, and CloudTrail (or the equivalent logging system for your cloud), and ship all of it to a single place.
Step 6: Cap the blast radius of always-on
Set spending caps on the model provider API key. If you run the agent in a container, set resource limits too. Then configure Hermes' own autonomy and approval settings conservatively: suggestions first, actions only once you've established trust.
Is My Hermes Agent Secure After These Six Steps?
If you followed every step above, your self-hosted Hermes Agent is dramatically safer than a default deployment. You've solved most of the problems a vanilla Hermes deployment has, and it took real work. Two problems remain:
- The agent still holds readable secrets.
- Your guardrails live in five different places, with no single view of what any agent can do.
That's where Lens Agents comes in.
Running Hermes on Lens Agents
Lens Agents is an agentic AI governance platform you install in your own environment with Helm. You can run Hermes fully sandboxed on the platform, and out of the box you get:
- Identity: Every agent in Lens Agents is a first-class principal with its own token, and all actions are attributed to the agent automatically.
- Default-deny networking: Kernel-level isolation with a policy-controlled proxy, including per-domain HTTP method and path restrictions.
- Real credential isolation: Credentials are applied at the platform boundary and never exist in the agent's environment.
- Audit trail: Every tool call, shell command, network request, and model invocation lands in one queryable place, exportable to your SIEM.
- Spending limits: Define limits per organization, per team, and per agent.
- AWS and Kubernetes integrations: Lens Agents integrates natively with AWS and Kubernetes, so your Hermes Agent can use them with governance in play.
Lens Agents supports Hermes out of the box, and creating a Hermes agent with all the governance in place is as simple as clicking a button:
Key Points
Hermes is a very capable autonomous agent, and the instinct to run it against real infrastructure is the right one — that's exactly where the value is. The biggest mistake you can make is running it with the access model of a shell script: your credentials, your host, open egress, and no audit trail.
Your organization will never agree to that, so make sure identity, default-deny networking, scoped credentials, containment, and audit are all in place when you work with Hermes.
You can also run Hermes on Lens Agents and get the whole model as the default, including the credential isolation you can't reasonably hand-roll.
If you want to see Hermes running governed against your own clusters and accounts through Lens Agents, book a demo with one of our engineers.
FAQ
What is Hermes Agent?
Hermes Agent is an autonomous, self-improving AI agent from Nous Research.
Is it safe to run Hermes Agent in an enterprise environment?
Running Hermes Agent with a vanilla setup, where you have open egress and all your credentials on the host, isn't safe. Running it with its own identity, default-deny networking, short-lived credentials, an audit trail, a contained runtime, and spending limits makes it enterprise-ready.
Can Hermes Agent read or leak my credentials?
Any secret available in your agent's environment can be read by the agent process, and by anything that compromises it. Scope your credentials narrowly, or better yet use a credential boundary where the agent never holds a usable secret at all.
What happens if Hermes Agent gets prompt injected?
With prompt injection, your agent will try to do something it shouldn't. Whether the attempt succeeds is decided by the infrastructure beneath it. With proper guardrails in place, even a fooled agent stays a contained one.
Do I still need governance if my Hermes Agent is read-only?
Yes, because exfiltration is still possible. Even a read-only agent can be used to steal your data if there are no guardrails in place.
Does running Hermes Agent on Lens Agents change how I work with it?
No. You get the same Hermes Agent and the same workflows you already use. The difference is that Hermes runs fully sandboxed with its own identity, credentials are applied at the network boundary instead of living in the agent's environment, and every action lands in an audit trail, so you always know what happened and when.