Deploying Hermes in an Enterprise Environment: Best Practices
An AI agent must first become a governed identity
An agent able to chain actions across your information system is not first a model question, but a question of identity, mandate and authorization.
We approach Hermes through IAM
Hermes can have memory, skills, independent profiles, scheduled tasks, MCP connections and access to tools or APIs. As soon as it enters an enterprise information system, the question is no longer «what can the AI answer?».
It becomes: what is its identity? Who authorizes it to act? On whose behalf? On which resources? For which action? And under which conditions?
An agent must be treated simultaneously as a non-human identity, an API client, possibly the proxy of a human user, and an autonomous process able to chain many actions without pausing for breath. These four readings do not call for the same controls, and that is precisely what makes the topic interesting.
A Hermes agent must have an identity
A Hermes profile has its own configuration, credentials, memory, sessions, skills and scheduled tasks. That is already a very useful basis for separation.
One nuance matters, though: a profile is a logical separation of Hermes state, not necessarily an operating-system security boundary. If the agent uses a local terminal backend, the profile alone does not prevent access to the rest of the filesystem. Sensitive environments must therefore also rely on proper isolation: Docker container, virtual machine, dedicated SSH backend, system permissions.
In an enterprise architecture, every significant agent should have its own identifier, a human or business owner, a purpose, an environment, distinct credentials, documented entitlements, a lifetime, and a review and revocation policy.
The model to avoid fits in one sentence we hear regularly: «here is my personal token, do everything I can do». A Finance agent, an SEO agent and a Delivery agent have no reason to share the same technical account just because they run on the same VPS.
This is exactly identity governance reasoning applied to non-human identities: they too have a lifecycle, entitlements, owners and access reviews.
«Acting on my behalf» does not require granting all of my rights
Hermes can use connectors and sometimes act with a delegated identity: reading mail, browsing documents, creating an event. For many use cases this is perfectly acceptable and saves real time.
For important resources, we often prefer another model: routing the agent through an API explicitly designed for the operations it is allowed to perform.
Rather than granting generic SharePoint access and relying on the prompt to keep the agent reasonable, you expose searchDocuments, readDocument and readMetadata — and you simply do not expose deleteDocument, changePermissions or shareExternally.
You may give up some of the convenience of native connectors. But once that API is built, the company genuinely controls what the agent can do, regardless of how its instructions are phrased.
Least privilege is no longer enough: aim for least capability to act
An agent is fast and autonomous. You must control what it accesses, but also what it can do and at what scale.
- 01
Document agent
Allowed to read documents in three specific workspaces. No deletion, no permission changes, no external sharing, a volume limit, and an anomaly raised if several thousand documents are suddenly accessed.
- 02
Mail agent
It can read certain mailboxes, search and prepare a draft. Sending may be allowed automatically internally, but require validation for an external recipient or a sensitive operation.
- 03
Finance agent
The fact that a human user can modify financial data does not mean their agent should be able to modify it without validation. The user's entitlement remains necessary; it must not always be sufficient.
The human identity and the agent identity must both be able to take part in the decision.
Put a PEP between the agent and the information system
The API Gateway is an excellent place to become a Policy Enforcement Point. It sits on the actual call path and intercepts the request before it reaches the resource. It can check the agent's identity, possibly the human identity it acts for, the API being called, the method, the parameters and the volume, then ask the PDP for a decision.
The Policy Decision Point decides. Axiomatics is a natural example in our ecosystem. The question is no longer «does this agent hold the SharePointReader role?», but «can the hermes-research agent read this Internal-classified document, in this specific site, for this specific user, as part of this task, with this risk level and this volume?».
The PDP returns a decision, the PEP enforces it: permit, deny, and depending on the architecture throttling, masking or a validation obligation. This is ABAC / PBAC logic. The PDP/PEP pairing is the reference architecture inherited from XACML, which does not mean modern integrations exchange raw XACML: REST/JSON interfaces fit today's API architectures perfectly.
The prompt describes what the agent should do. Authorization determines what it can actually do.
Initial request, scheduled task
Agent with its own technical identity
Tooled call into the information system
Enforcement point: intercept, enrich, enforce
ABAC / PBAC decision: permit, deny, obligation
The resource is reached only after the decision
Enforcement happens before the data enters the model's context, not afterwards on its answer.
A concrete example: Hermes needs to read SharePoint
The bad shortcut is to give the agent very broad SharePoint access because «the user has access anyway». Yet the blast radius changes scale: a human opens a few documents, an agent can go through several hundred in minutes.
The architecture we prefer chains Hermes Research, an Enterprise Documents API, the API Gateway acting as PEP, the Axiomatics PDP, then Microsoft Graph and SharePoint.
For SharePoint Online, Microsoft Graph notably supports Selected permissions, which restrict an application to specific resources instead of granting global access. Controls exist at site, list, item, folder or file level depending on the scope used. The application identity behind the API then only holds read access to a few authorized sites.
Hermes asks to «read document-123». The PEP passes the request attributes to the PDP.
Axiomatics evaluates the policy. If the answer is Permit, the API calls Microsoft Graph. Otherwise the document never reaches the agent's context — and that is the essential point: the control must happen before sensitive data is passed to the model, not only by trying to filter its answer afterwards.
human = requesting user
agent = hermes-research
action = read
resource = document-123
classification = internal
site = sales
purpose = customer-research
risk = low
volume_last_15_minutes = 12Fine-grained dynamic authorizationAxiomatics partnershipAccess management and CIAMBlast radius — glossary definition
Also use Hermes' native protections
Hermes is not inherently dangerous. It already ships several useful controls: authorizing who may talk to the agent, validating dangerous commands, write restrictions, container or remote-backend isolation, MCP credential separation. They should be used.
But they mostly address runtime security. The IAM architecture described here answers a different question: even if Hermes behaves exactly as intended, which actions is the company willing to let it perform? The two layers are complementary, and neither replaces the other.
This architecture also applies to Emergent Wingman
Wingman offers connectors to many SaaS platforms and has its own controls: connector permissions, action policies, confirmations, sandboxing, scheduled-task protection and audit logs.
The difference lies in the trust boundary: the agent runs outside your information system. For low-risk operations, a native connector is often enough. For a sensitive operation, the same pattern — Wingman, then enterprise API, then API Gateway / PEP, then PDP, then resource — keeps the authorization decision under the company's control.
So there is no need to oppose Hermes and Wingman: the architecture is reusable for both, with an even more structuring entry point for an agent outside the information system.
Minimum recommended architecture before production
- A distinct identity per agent or area of responsibility.
- A governed owner and lifecycle.
- Short-lived, least-privileged credentials.
- Explicit APIs for sensitive actions.
- A PEP able to query a fine-grained authorization PDP.
- Logging that connects human → agent → decision → API → resource.
An autonomous agent does not need to be an administrator to be useful. A good architecture gives it plenty of autonomy inside a tightly controlled authorization perimeter.
Key takeaways
Identity governance governs identities and entitlements over time. Access management handles authentication and access. Fine-grained authorization makes the contextual decision at runtime. An AI agent needs all three, not just a good system prompt.
An agent's value comes from its autonomy. The role of IAM is not to reduce it, but to make it enforceable: a clear perimeter, decided somewhere other than in the agent's instructions.
Frame your agents before putting them in production
We help teams define their agents' identities, the APIs they actually want to expose, the enforcement points and the associated authorization policies — starting from business use cases, not from a tool catalogue.