Framework
Six Acceptance Gates for an Enterprise Agent
A useful pilot must demonstrate bounded authority, recoverable execution and a measurable business result. This framework turns those requirements into a release decision.
Why the acceptance brief needs to change
NVIDIA’s 28 September Open Agent Safety Platform announcement combines OpenShell runtime controls with a Sentry reference design for independent monitoring. SAP’s same-day update describes work to connect runtime isolation with business authorisation in Joule Studio. Neither announcement removes the buyer’s obligation to validate its own deployment.
The distinction matters: containing software and authorising a business action are related but separate problems. The following six gates are an editorial evaluation framework, not a certification scheme from either vendor. They are intended for an agent that can use enterprise tools and change business records.
Choose one consequential workflow
Begin with a bounded task, such as preparing a service adjustment for approval. Write down the starting state, the permitted outputs, the records that may change and the person who owns the outcome. Include what the agent must decline or escalate.
Use a representative set of normal cases, incomplete inputs, conflicting instructions and unavailable dependencies. Business owners should define acceptance thresholds before testing, including which errors are release blockers. Do not average a serious unauthorised action into an otherwise attractive success rate.
Make failure evidence part of the deliverable
A release review needs more than a recording of the demonstration. Retain the requested action, the evaluated permissions, relevant tool responses, the final system state and any human intervention. Protect sensitive information in those records and define who may access them.
The team should demonstrate how an operator pauses execution, prevents a duplicate action and reconciles a partially completed transaction. Recovery may require a compensating business action rather than a technical rollback. That distinction should be agreed with the process owner, not discovered during an incident.
Use staged authority
A sensible progression is observation, preparation, supervised execution and then bounded autonomous execution. Moving between stages should depend on evidence from the previous stage and the consequences of error. It should not be tied only to a project calendar.
For example, an agent may be approved to draft adjustments but remain unable to apply them. That is an explicit release boundary, not a failed transformation. Expanding the scope later should require a new evaluation of permissions, monitoring and operating capacity, because a broader tool set changes the risk even if the model stays the same.
Working framework
The six gates and their evidence
- Purpose: a named business owner accepts the task definition, baseline and completion criteria.
- Authority: allowed and denied actions are tested under the real identity and permission model; material violations block release.
- Containment: verify that the deployed runtime enforces the agreed access and execution boundaries, including when an agent requests more access.
- Recovery: demonstrate safe stopping, duplicate prevention and reconciliation after partial completion.
- Evidence: reconstruct representative decisions from protected logs without relying on the agent’s own explanation alone.
- Operations: name the support owner, capacity limits, change-review process and conditions for withdrawing autonomous authority.