At an AI agent's readiness review, ask the implementation team to attempt an action the business has prohibited. If the agent is allowed to prepare a customer response but requires approval to send it, test the send step without approval. Inspect the system that blocks the action and the record it leaves. A demonstration in which the agent politely agrees to wait does not establish that the boundary is enforced.
Successful work is part of the acceptance test. The other part is showing what happens when the system reaches a limit, receives conflicting information, or tries to proceed without the authority it needs. Those tests belong before the agent gets access to live business systems.
Separate behavior from permission and quality
An instruction tells an agent how to behave. A permission determines which operations the surrounding system will allow. A quality check determines whether the permitted work is acceptable. Each answers a different question, and all three need attention.
Consider an agent that prepares replies to customer support requests. Its instructions say to use approved information, avoid promising exceptions, and send nothing until a person approves. The tools it receives should support those boundaries. If the same connection allows it to send messages freely, the business is relying on compliance with an instruction for a consequential action. An enforced approval step checks authorization before the send is allowed, regardless of the agent's explanation for proceeding.
That control still says nothing about the accuracy of the draft. An agent can remain inside every access boundary and prepare a wrong answer using an outdated policy. It can also prepare an accurate response for the wrong customer. Security testing and business-quality evaluation have to meet at the completed workflow without being confused with each other.
Test the control outside the conversation
NVIDIA's March explanation of OpenShell describes a runtime intended to enforce policies outside the agent, including controls over filesystem, network, and process access and records of allow and deny decisions. The announcement identifies OpenShell as an early preview. Its design illustrates a useful separation of responsibilities; the announcement itself is not proof that a particular deployment is secure.
A buyer should ask the same questions regardless of the product used. Where is the rule enforced? Who can change it? Which routes to the external system does it cover? What happens if the approval service is unavailable? If the restricted action is still reachable through a second tool or a more privileged connection, the visible approval screen does not define the real boundary.
The test needs to distinguish an agent choosing not to act from a system rejecting an unauthorized attempt. Both are useful observations. Only the second demonstrates the control at the point being tested. Use a safe test environment with representative permissions, and verify the resulting state as well as the agent's report. A log saying that a send was blocked should agree with the absence of an outgoing message.
Make failure cases part of acceptance
For the support workflow, the test set should include a request with no approval, approval for a different customer, and an approved draft whose recipient or material content changes before sending. Decide which changes invalidate approval and enforce that decision. An approval should apply to a defined action, not become a reusable permission slip for whatever the agent decides to do next.
Also test the information boundary. Put instructions in a sample customer message asking the agent to ignore its rules or disclose another customer's information. That content is something to process, not a source of authority. Check whether the system preserves that distinction and whether the tools prevent access to records outside the task's permitted scope.
Then test ordinary operational failures. Let a send request time out after the receiving service has accepted it. The workflow needs to determine whether the action already happened before retrying. Repeating an external action because the agent did not receive a clean response creates a different class of failure from a bad draft, but the customer experiences the result just the same.
For each case, record the expected outcome, actual outcome, relevant permissions, and evidence. Failures should identify a responsible owner and a condition for retesting. A demonstration selected by the builder is useful for explaining the system. Acceptance requires cases chosen to challenge the assumptions on which the system relies.
Define when a person takes responsibility
In Agency and Agents, published August 31, Ethan Mollick argues for involving people when agents need approval or expertise, rather than treating minimal human participation as the objective. That distinction belongs in the operating design. Some work needs authorization to proceed; other work needs judgment the system cannot supply reliably.
Specify who receives each kind of escalation, what they need to see, and what happens while they are unavailable. A queue without an owner leaves work stranded. An agent that interprets silence as permission removes the safeguard. The team should also demonstrate how it stops further activity, preserves the evidence, and corrects completed work when correction is possible. Sent messages and external commitments do not disappear when a process is restarted.
Passing these tests provides evidence about a defined version of a workflow under the conditions tested. Changes to tools, permissions, approval logic, and models require a review of which tests must run again. The tests do not establish that every future failure has been anticipated, but they make the business's stated limits inspectable and repeatable.
Before an agent goes live, ask the team to show a prohibited action being blocked, explain where the block is enforced, and produce the evidence. Then ask whether the work it is allowed to complete meets the business's standard. Production readiness requires clear answers to both.