The HyperShell platform
Govern every agent task. On the runtime you choose.
HyperShell is the governance layer for enterprise agents: Envelopes that define authority, enforcement inside the sandbox and at the MCP and LLM gateways, and run evidence your security team can review.
Run it on NVIDIA OpenShell in your data center, or on Amazon Bedrock AgentCore in your AWS account. Your existing identity provider stays in place.
The stack
One supported stack, from your IdP to the runtime.
The runtime runs the agent. HyperShell governs the task. Each layer does one job, and HyperShell supports the connection between them.
Your enterprise IdP
Workforce identity and authentication stay where they are.
- Agent identity
- Envelopes
- Policy at execution
- Cost controls
- Run evidence
On-premises
Your data center
NVIDIA OpenShell
Available through Mirantis Enterprise AI
Agent sandbox
Inference: local or cloud
Cloud
Your AWS account
Amazon Bedrock AgentCore
Agent sandbox
Inference: your AWS models or providers
Stays in your environment: the runtime and its policy, agents and their working state, source code, data, logs and run evidence.
Hosted model inference (optional)
The only thing that can leave, and only if you choose a hosted model.
One vendor, one support contract for the platform and its connection to each supported runtime.
We confirm runtime, tool and model coverage with you during scoping.
HyperShell is not affiliated with NVIDIA or AWS. HyperShell platform capabilities and services are separate from the upstream open source and cloud services they run on.
Agent Envelopes
Admins define the envelope. Users build agents inside it.
An Agent Envelope is the authority for a defined task: the tools and data, actions, delegation, models and spend an agent may use. It is enforced on each supported runtime, and helpers can only receive the same or narrower limits.
Developer template: up to $25 per month, 3 tools, 24h lifetime
Sample values.Within the ceiling: provisioned automatically
Above the ceiling: goes to the admin inbox
Admin inbox
- 01
Admin sets the ceiling
An administrator publishes a template revision for a role, labeling tools as read, write, or destructive.
- 02
User requests within it
An engineer picks a template and narrows it for their agent. Requests inside the ceiling are provisioned without waiting for approval.
- 03
Exceptions are reviewed
Requests above the ceiling, or runs that hit a cumulative limit, go to one admin inbox with the difference shown.
See templates and the requests inbox in the product walkthrough.
Product walkthrough
Same governance. Your runtime.
Authority you can trace from the grant to the tool call.
Delegation
Grants, requests and expiries for every person and agent. Helpers can delegate only what they hold.
Compare approaches
Gateways see tool calls. HyperShell governs the whole task.
Agent controls overlap. The difference is what authority is scoped to and where it is enforced.
Identity provider tokens
Agent gateways
HyperShell
One Envelope, end to end
| Approach | Unit of authority | Delegation to helpers | Where limits are enforced | Evidence shows |
|---|---|---|---|---|
| Identity provider tokens | User context and token scopes | Token scopes | Applications, APIs and MCP | Who accessed which API |
| Agent gateways | Agent identity and credentials | Per agent configuration | Gateway and connected tools | What was called |
| Just in time access | Scoped, short-lived credentials | Varies | Connected tools and resources | Which credentials were used |
| HyperShell | A task Envelope tied to the person or organization granting it | Equal or narrower limits only; more needs new approval | Inside the sandbox plus MCP and LLM gateways | Whether the agent stayed inside the grant |
Identity provider tokens
- Unit of authority
- User context and token scopes
- Delegation to helpers
- Token scopes
- Where limits are enforced
- Applications, APIs and MCP
- Evidence shows
- Who accessed which API
Agent gateways
- Unit of authority
- Agent identity and credentials
- Delegation to helpers
- Per agent configuration
- Where limits are enforced
- Gateway and connected tools
- Evidence shows
- What was called
Just in time access
- Unit of authority
- Scoped, short-lived credentials
- Delegation to helpers
- Varies
- Where limits are enforced
- Connected tools and resources
- Evidence shows
- Which credentials were used
HyperShell
- Unit of authority
- A task Envelope tied to the person or organization granting it
- Delegation to helpers
- Equal or narrower limits only; more needs new approval
- Where limits are enforced
- Inside the sandbox plus MCP and LLM gateways
- Evidence shows
- Whether the agent stayed inside the grant
HyperShell works with your existing identity provider and runtimes rather than replacing them. Category comparison based on vendor documentation.
How we start
A supported path to your first governed workflow.
01
No costScope
Workflow scoping session
Pick one workflow. Agree on its access and spending limits and a measurable success criterion.
02
Scoped separatelyDeploy and build
Implementation engagement
HyperShell engineers deploy the platform in your environment, connect approved systems and build the first workflow with your team.
Run and expand
Annual subscription
Governance platform, supported runtime management and ongoing support. Add workflows, users and agents as you grow.
Plans
Annual subscription tiers
Every tier includes the governance platform, supported runtime management and support.
Department
Contact us
Annual subscription
- 25 delegated-agent users
- 5 autonomous agents
- 500 interaction-only users
- Business hours support
Business unit
Contact us
Annual subscription
- 200 delegated-agent users
- 20 autonomous agents
- 2,500 interaction-only users
- Priority business hours support
Enterprise
Contact us
Annual subscription
- 1,000 delegated-agent users
- 50 autonomous agents
- 10,000 interaction-only users
- 24/7 support for critical incidents
- Delegated-agent users grant personal access.
- Autonomous agents carry organizational authority.
- Interaction-only users request, review or approve work.
Add users, agents and capacity to any tier. Cloud usage, model fees and on-premises infrastructure are paid separately. Implementation is scoped separately.
Plan your first governed workflow.
Tell us which workflow you want to govern, which systems it touches, and the controls your team needs.