Governed Execution Platform · design-partner preview
Govern AI execution.
Not just AI access.
Give people, automation, and AI agents a governed path to operational systems — without giving them unrestricted execution authority.
resh evaluates policy before a consequential change, holds it for an authorized approver where policy requires one, executes the bounded operation, independently verifies the resulting state, and preserves the evidence from request through outcome.
For DevOps, SRE, platform engineering, and security operations teams. resh is a pre-GA design-partner preview, evaluated in controlled, non-production environments.
The problem
Authorization decides whether an action may be attempted.
It does not tell you what changed.
AI agents and automation can increasingly act on production, not just read from it:
- restart services
- change infrastructure
- operate containers
- modify operational state
- invoke consequential APIs
- perform remediation
What identity, gateways, and authorization answer
“Who or what is acting? May it reach this system, or call this tool?”
A yes here is a statement about the caller and the call. Those controls are necessary, and resh replaces none of them. On its own, that yes does not bound what happens at the resource or establish whether it worked.
What governed execution answers
“Should this specific change be allowed to execute, against this resource, under these conditions, right now — and did the intended state actually occur?”
A yes here is a statement about the change. It is the one an incident review and the owner of the service are both asking for.
Authorized is not executed, and executed is not verified. A permitted operation can still fail to run, and one that ran can still leave the resource in the wrong state. resh records each as a separate fact.
That second question is a category of its own. Read what governed execution is and how it differs from access governance.
How resh answers it
Govern. Execute. Verify.
resh is the governed execution layer between operational intent and consequential change. Three principles, then a durable record of what happened.
Govern before execution
Identity, target, operation, policy, and any required approval are evaluated before the change executes — not reconciled from logs afterwards.
Execute with bounded authority
Only the permitted operation runs, against the resource that was resolved. There is no shell underneath it and no adjacent capability to reach for.
Verify the outcome
resh observes the resulting state itself rather than trusting a provider, an API, or an agent reporting success.
The governed execution lifecycle in six stages. One: a request, naming a resource and an operation. Two: governance, where policy is evaluated before anything runs and can refuse. Three: approval, where policy requires it, which can be declined. Four: execution of the bounded operation. Five: verification, where the resulting state is observed rather than reported, and which can report failure. Six: evidence, the durable record.
The same path applies whether the request came from a person, a script, or an AI agent. Follow one service restart through the governed execution platform.
Applications
One governed estate.
Multiple operational purposes.
Applications give each team a purpose-oriented operational surface over the same enterprise estate — Security Operations, Deployment Operations, Platform Operations. A team sees and works with the resources that matter to its purpose.
An Application can determine whether someone may inspect or request an operation through that purpose. It does not grant the authority to execute the operation.
The target runtime independently applies canonical governance before the operation executes.
The same resource can appear in more than one Application — a service that matters to both Security Operations and Deployment Operations, for example. Membership is organizational: it grants no execution authority, and every request still passes through its own Application scope and the runtime’s governance. Applications are not tenants.
Diagram of one resh Enterprise estate containing two Applications. Security Operations contains a scanner service and a shared API service. Deployment Operations contains a web service and the same shared API service. Each Application decides who may see its resources and who may request operations through it. A request from either Application — which is a request, not authority to execute — goes down to canonical runtime governance, where the runtime that owns the resource independently decides whether the operation may execute, applying policy and approval where required. Only if governance allows does governed execution follow: the bounded operation, verification, and Activity and Evidence.
AI and automation
AI can request. Governance decides.
resh executes and verifies.
An AI agent does not need unrestricted shell authority simply because it needs to perform an operational action. Its requests stay subject to identity, Application scope, runtime policy, approval where required, bounded execution, verification, and evidence — the same path a person’s request takes.
A comparison of two ways to let an AI agent restart a service. On the left, the agent is given shell or API credentials: the path is agent, then a shell, then the system. What is granted is everything the account can reach; what policy sees is an opaque command; success is whatever the agent reports. The conclusion is that the authority granted is far wider than the task. On the right, the agent is given a governed request path: the path is agent, then a governed request, then resh, then the operational resource. What is granted is permission to ask for a modelled operation on a named resource; runtime governance decides whether it may execute; and success is the state resh observed afterwards. The conclusion is that the agent can ask, and cannot simply do.
resh governs modelled resource operations, not arbitrary commands. A system that has no provider is outside the boundary rather than reachable through a fallback.
Verification
Execution success isn’t operational proof.
An API may return success. A provider may report success. An AI agent may say it completed the task. None of those alone proves the intended state exists.
resh independently observes the resulting resource state and records the verified outcome separately from the execution result. Where an operation declares no way to be observed, verification is reported as unsupported — never assumed.
- requested
- svc://api-service · start
- execution
- executed — the service manager reported success
- observed
- the service is not running
- verification
- failed
A start request on a service that does not stay up, shown with the provider’s own post-start check switched off. The call succeeded and the outcome did not, and resh reports both. With that check on, the same request is reported as a failed execution instead.
Activity & Evidence
The questions that get asked afterwards.
- Who requested the change?
- What resource was targeted?
- What operation was requested?
- What governance decision applied?
- Was approval required, and who approved?
- What executed?
- What state was observed afterwards?
- Was the intended result verified?
Activity & Evidence records the answers as structured data. It is an operational record, not a compliance certification: this release signs nothing cryptographically and offers no write-once storage.
What changes for the team
The point is not more control. It is more automation.
Organizations do not block agents from production because they dislike automation. They block them because the only lever available is all-or-nothing.
Say yes more often
The usual answer to "can the agent do this?" is no, because the only options are broad access or none. A bounded, governed operation is a third option.
Spend review where it counts
Policy decides which changes need a person. Routine operations stop consuming a reviewer, and consequential ones stop slipping past one.
Answer "what happened?" directly
Who asked, what was decided, who approved, what ran, and what was observed afterwards are one linked record rather than a correlation exercise.
See the scenarios for DevOps, security operations, and AI-assisted operations.
Where resh fits
What resh is not.
resh sits between intent and operational change. It is easiest to place by ruling out what it is most often mistaken for.
Keep the controls you have. Add governance where the change lands.
Identity establishes who or what is acting. A gateway and its authorization decide which tools that caller may reach. resh is designed to sit after both, at the resource: it decides on the specific operation, runs it through a bounded capability, reads the resulting state back, and records the evidence.
That placement is independent of which agent platform, pipeline, or person the request came from, because the decision is made by the runtime beside the resource rather than inside the system that asked.
This is architectural placement, not a list of integrations. This release ships no connector to an identity provider, a privileged access manager, or a gateway: a caller reaches resh through its command line or HTTP API with a resh-issued credential, and the resources it can govern are those on Linux hosts that a provider models.
A top-to-bottom placement diagram in five layers. First, identity and access — an identity provider and privileged access — establishes who or what is acting. Second, an authenticated caller reaches the gateway and authorization layer — an agent or MCP gateway and runtime authorization — which decides which tools a caller may reach and whether a call may be attempted. Third, a request for one operation on one resource reaches resh governed execution, which governs the change itself at the runtime beside the resource: resource identity, runtime policy, approval where required, and bounded execution. Fourth, a bounded operation reaches the resource — the service, container, configuration, or file that actually changes. Fifth, the resulting state is read back independently by resh and recorded as verification and Activity and Evidence, with the request, the decision, and what ran.
Not an AI agent framework
resh builds no agents and hosts no models. It governs the point where an agent tries to change something real.
Not CI/CD or a workflow engine
Pipelines and orchestrators decide what should happen and when. resh governs the moment that decision becomes a change to a specific resource.
Not an identity provider
resh establishes who is asking with its own issued credentials and does not replace your identity or access management.
Not an agent or MCP gateway
A gateway decides which tools a caller may reach. resh brokers no tool traffic; it governs one operation on one resource, wherever the request came from.
Not privileged access management
resh brokers no host session and issues no host login to a person or an agent. A caller requests one modelled operation on a named resource, not a shell.
Not an observability or audit product
Logs record what a system was told. resh’s evidence also carries the decision and the state observed afterwards — and half of what resh does happens before the change, where it can still be refused.
Where resh is today
A design-partner preview, described as one.
resh 0.2.0-rc.10 is pre-GA. It runs on supported Linux hosts and is evaluated in controlled, non-production environments. There are no production customers, no compliance certifications, and no availability commitments on this site.
The current limits — including no enterprise single sign-on and nothing cryptographically signed — are published on the design partner page so you can rule resh out before spending a meeting on it.
Open-source foundation
Built on Resource Shell.
Resource Shell is the open-source project behind resh’s execution model: systems expose typed operations on named resources instead of unrestricted command authority.
resh Enterprise is the commercial product built on it, adding Applications, central administration, approval visibility, and aggregated Activity & Evidence across an estate.
Common questions
What people ask first.
- What is resh?
- resh is a Governed Execution Platform: the layer between operational intent and consequential change. People, automation, and AI agents request operations on modelled resources — restart this service, for example — and resh evaluates policy before anything runs, holds the request for an authorized approver where policy requires one, executes the bounded operation, independently checks the resulting state, and records what happened.
- How is governed execution different from access control?
- Access control answers who can connect or who can call the API. Governed execution answers a later question: should this specific change be allowed to execute, against this resource, under current policy, right now — and afterwards, did the intended state actually result? A valid credential says something about the caller. It says nothing about the change.
- Does resh replace an identity provider, privileged access management, or an agent gateway?
- No. Those establish who or what is acting and which systems or tools it may reach, and they stay where they are. resh is designed to sit after them, at the resource: it decides on the specific operation, executes it through a bounded capability, observes the resulting state, and records the evidence. That is architectural placement rather than a set of integrations — this release ships no connector to an identity provider, a privileged access manager, or a gateway, and callers reach resh’s HTTP API with resh-issued API keys.
- How is this different from giving an AI agent shell or API access?
- A shell grants authority over everything the account can reach, and a command string is opaque to policy until it has already run. With resh an agent is given a governed request path instead: it names a modelled resource and a typed operation, so the target and the operation are known before execution and policy decides on that specific change. resh supports modelled resource operations; it does not govern arbitrary commands, and a system with no provider is outside the boundary.
- What is an Application in resh?
- A purpose-oriented surface over one governed estate, such as Security Operations or Deployment Operations. Application permissions decide who may inspect resources and request operations through that purpose. They do not grant authority to execute: the target runtime independently applies its own governance before anything runs. Applications are not tenants, and the same resource can belong to more than one.
- Does every operation need a human approval?
- No. Approval is part of runtime governance where policy requires it. Policy can allow an operation, refuse it, or require an authorized approval before it is allowed to continue. An approver must be named by runtime policy and cannot be the requester, and being able to request an operation — as a person, a service, or an AI agent — confers no approval authority.
- What does "verified" mean?
- That resh looked. After an operation runs, resh takes a separate observation of the resource and checks it against the post-condition the provider declared for that operation — a start is confirmed by reading the service state, not by the start call returning. An exit code or an API success is an execution result, not a verified outcome. Where an operation declares no way to be observed, resh reports verification as unsupported rather than assuming success.
- Why is an audit log not enough?
- An audit log is worth keeping, and resh does not replace one. A log entry can show that a caller invoked a tool at a certain time and that the call returned. The evidence resh records is built to carry the rest of the chain: who requested the change, which resource and operation, the governance decision, who approved, what executed, the state observed afterwards, and whether that state met the post-condition declared for the operation. It is an operational record, not a compliance certification.
- Is resh only for AI agents?
- No. The governed path does not depend on a model or an agent framework: a request from a person, a script, or an AI agent names a resource and an operation and is governed the same way. AI agents are why the problem is urgent now, and AI-assisted infrastructure operations are what the design partner program is focused on.
- Is resh an AI agent framework, a CI/CD tool, or a workflow engine?
- None of those. resh builds no agents and hosts no models, orchestrates no pipelines, and is not a general workflow or business-process automation platform. Those systems decide what should happen. resh governs the moment a decision becomes a change to a specific operational resource, whoever or whatever asked for it.
- Is resh generally available?
- No. resh is a pre-GA design-partner preview. Evaluations run in a controlled, non-production environment on supported Linux hosts. There are no production customers, no compliance certifications, no service-level commitments, and no enterprise single sign-on in this release — operators authenticate with issued API keys. The current limits are published on the design partner page.
- What does the design partner program involve?
- A free, guided technical evaluation — not a purchase and not a licence. You bring one consequential operational workflow, and we work through whether it can be governed from request through verified outcome in a controlled, non-production environment. We ask for candid technical feedback in return, and concluding that resh is not a fit is a legitimate result.
Design partner program
Bring us one consequential operational workflow.
We are working with a small number of DevOps, SRE, platform, and security operations teams to find out whether a real operational change can be governed from request through verified outcome. It is a free, guided evaluation in a non-production environment — and we will tell you where this release does not yet have a good answer.