AI Vendor Evidence Gap Notes #11
The first ten notes focused mainly on vendor claims and the evidence behind them.
There is another evidence problem once the documentation looks complete.
A vendor may have a policy, workflow diagram, product documentation, and configuration showing how an AI agent is expected to behave.
That does not show whether the control is enforced when the agent actually runs.
Claim
The documentation says:
“High-risk actions require human approval.”
The policy defines the requirement.
The workflow contains an approval step.
The product may provide a setting for it.
These are useful evidence of the intended control.
They do not show that every qualifying action is actually stopped and sent for approval.
Why it sounds sufficient
Policies and configuration are familiar review artifacts.
If the approval rule is documented and the feature is enabled, it is easy to record human oversight as an implemented control.
The problem is the execution path.
An agent may select tools, call APIs, retry failed actions, or reach the same result through a different sequence.
A reviewer therefore still needs to know:
what triggers approval;
whether execution stops before the action;
what happens after rejection;
how retries are handled;
whether another tool path can avoid the trigger;
what happens if the approval mechanism fails;
whether the approval can be linked to the final action.
Those questions cannot be answered by the policy alone.
What it actually proves
A policy can show that the control was defined.
Product documentation can show that an approval mechanism exists.
Configuration evidence can show that it was enabled.
These support control design and configuration.
Evidence of enforcement comes from somewhere else.
For example, an execution record could show:
Trigger: The agent attempted an action requiring review.
Pause: The action stopped before execution.
Reviewer: The request was sent to an attributable reviewer.
Decision: Approval or rejection was recorded.
Execution: The action occurred only after approval.
Trace: The approval event and final action can be linked.
That is evidence about what happened, not only what was supposed to happen.
A public evidence example
The CodeYourCompliance Trust Signal profile for Decagon shows the distinction at the public-evidence layer.
The profile identifies security and AI data-usage surfaces, along with enterprise evidence such as audit logs and AI guardrails. It also keeps an explicit boundary: those public security materials are review surfaces, not implementation verification.
That boundary becomes important for agent controls.
Trust Signal can help locate the documented evidence surface.
It cannot show, by itself, whether a guardrail or approval control was enforced in a particular execution.
What it does not prove
A documented approval control does not automatically establish:
Trigger coverage. The rule may exist without showing that every relevant action is detected.
Bypass resistance. Another tool or workflow may reach the same outcome without triggering approval.
Failure behavior. Documentation may not explain what happens when the approval service fails or times out.
Retry behavior. A rejected action may be attempted again through a different path.
Sequence. An approval record is weak evidence if the action could occur before approval was captured.
Version applicability. Evidence collected against one model, prompt, tool configuration, or agent version may not remain valid after those components change.
Weak-answer pattern
A common answer is:
“Human approval is required for high-risk actions. See our policy and product documentation.”
That may be enough to support the existence and design of the control.
The gap appears when the review stops there.
The buyer has evidence of the rule, but not yet evidence that the rule intercepted the relevant action during execution.
Evidence request
For controls that limit what an agent can do, ask for evidence from the execution path:
Provide evidence showing how actions requiring human approval are identified, paused, presented for review, approved or rejected, and linked to the final execution record. Include rejected actions, retries, alternate paths, and approval-service failure where available.
Useful evidence may include execution traces, approval logs, reviewer identity or role, timestamps, tool-call records, rejected-action records, failure tests, and bypass tests.
The purpose is not to collect more logs.
It is to connect the documented control to the behavior it is meant to constrain.
Review note
Human approval is documented as a control for high-risk actions. The available evidence supports control design, but enforcement across triggering conditions, retries, alternate execution paths, and failure conditions has not yet been demonstrated.
Usage boundary
Until enforcement evidence is available, a documented approval requirement should not be treated as proof that high-impact autonomous actions are consistently intercepted.
For higher-impact use cases, keep the agent within a boundary where failure or bypass of the approval step cannot independently create a consequential action.
The evidence question is no longer only:
What does the policy say?
It is also:
What happened when the control was tested?
Boundary
This material is for evidence structuring and review preparation.
The goal is to make the gap between documented controls and demonstrated behavior visible before those controls are relied upon.
#AIAssurance #AIGovernance #AIAgentTesting