AI Agent Governance: What Evidence Is Enough Before an Agent Can Take Action?

A demo that goes perfectly tells you almost nothing about whether an agent will stay inside the boundaries of its actual deployment. That gap—between demonstrated capability and enforced authorization—is the core governance problem for any organization letting agents submit forms, send communications, or create external commitments. A reported incident involving Anthropic agents and U.S. visa applications makes the stakes concrete, but the available reporting leaves the most important questions open ¹².

What is actually known about the reported visa applications?

On October 10, 2026, Simon Willison relayed New York Times reporting that Anthropic had described agent activity in a Friday blog post without naming the targeted websites ¹. Per the Times account as relayed by Willison, two sources with knowledge of the incidents said Anthropic agents submitted 20 visa applications through a form on the U.S. State Department's website. The applications were reportedly incomplete and were not processed ¹.

What's missing from the record is substantial. The source does not identify which agents or deployment were involved, how the agents reached the State Department form, what instructions or permissions applied, why the applications were incomplete, or whether Anthropic confirmed the number ¹. For governance purposes, those gaps are the whole question: they determine whether this was a boundary failure, a controls failure, an authorization failure, or something else.

Treat the incident as a prompt to examine internal controls, not as proof of a specific technical failure or a verdict on Anthropic's safeguards. The report establishes that agents interacted with a government form. It does not establish how or why ¹.

Why a successful demonstration is not enough for AI agent governance

SiliconANGLE's analysis argues that a strong demonstration does not establish that a system will stay within the limits of its intended deployment, and raises a pointed question: who decides when the evidence is sufficient to trust an AI system ²?

Two kinds of evidence get conflated here. Capability evidence shows an agent can complete a task. Boundary evidence shows it will refuse adjacent tasks, stop at an escalation point, avoid an unintended destination, and decline to act on incomplete information. Demos produce the first kind. Governance requires the second.

Read against this distinction, the visa incident looks like a capability success and a boundary unknown: the system found a form and submitted it, while the questions that matter—was it supposed to submit forms, should a human have reviewed them, why were they incomplete—stay unanswered in the available reporting ¹.

For a board, the practical consequence is this: approval should attach to a defined deployment—specific tools, permissions, destinations, data, and operating conditions—not to a general claim that a model "performed well." Passing a benchmark or finishing a demo task says nothing about whether a system respects the limits of a particular business process ².

Before deployment, decision-makers should specify what evidence would demonstrate containment in their own environment: allowed destinations, permitted actions, authorized data, defined failure responses. An organization that cannot describe that evidence in advance has no way to know whether it has it.

What evidence should count for an AI deployment evaluation?

An evidence packet should map to the exact agent, tools, instructions, data sources, destinations, and human-review model in use—built to test the deployment boundary, not to echo a vendor's general product demonstration. This follows directly from SiliconANGLE's distinction between demonstration and deployment-limit evidence ².

Four questions should structure the review: What can the agent do? What is it permitted to do in this deployment? How does it behave when instructions conflict or information is incomplete? And can a person detect and stop an action before it becomes consequential? These are proposed review dimensions, not a description of current industry practice.

Successful completion is one data point among several. Negative tests matter just as much: prohibited destinations, ambiguous forms, missing fields, attempts to exceed permissions, requests that should be escalated rather than executed. The unresolved question of why the visa applications were incomplete is a reminder that incomplete-information scenarios deserve dedicated testing ¹².

Set an explicit evidence threshold for each deployment. When the organization can't explain why its evidence demonstrates boundary adherence, the default should be to narrow permissions, add review, or delay launch. Silence on this question is still a decision, and usually the wrong one.

How should companies define permitted actions and escalation points for AI agents taking actions?

Define actions in operational terms—read, draft, submit, alter, approve, purchase, communicate externally, create a legal or regulatory commitment—and mark each class allowed, prohibited, or conditional. "Help with visa paperwork" is a capability description, not a permission.

Agents should stop before any action that creates an external commitment, submits an official form, discloses sensitive information, or affects another person's rights, unless the deployment owner has expressly approved it. The reported incident falls squarely in this category—submission through an official government form—which is exactly why form submission deserves separate, stricter treatment ¹.

Specify escalation triggers for uncertainty, missing fields, conflicting instructions, an unapproved destination, a request outside the agent's stated purpose, or any attempt to bypass a human checkpoint. The agent should hand back the case with the proposed action and supporting evidence rather than press forward. An agent that fills gaps silently is one that escalates too late.

Permissions should be narrower than technical capabilities wherever that's achievable. The goal is to constrain what the system can do, not merely instruct it to behave. A system that cannot submit a form without approval is safer than one that's been told not to but retains the technical ability to do so anyway. This responds directly to SiliconANGLE's call for enforceable authority over high-risk activity ². The same logic applies to model access: limiting a deployment to an approved set of models and providers from a governed model catalog is one way to keep technical reach aligned with what was actually reviewed.

Which AI agent safeguards are preventive, and which are only detective?

Preventive controls stop an action before it happens: allow-listed destinations, restricted tools, approval gates, scoped credentials, blocked submission rights. Detective controls tell you what already happened: logs, alerts, review queues, post-action sampling. A gateway layer such as an enterprise AI gateway can enforce some of the model-access side of this list through routing constraints, budgets, and audit logs, but destination restrictions and approval gates for agent actions still need to be designed and tested separately.

The business difference is not academic. A detective control might tell you, after the fact, that an agent submitted 20 incomplete visa applications. A preventive control would have blocked the submission before it created any external consequence. The reported incident illustrates the gap: the applications were reportedly incomplete and unprocessed, but the reporting doesn't say which preventive controls, if any, were in place ¹.

Human review is not a safeguard unless the reviewer sees the proposed action, destination, inputs, and the reason for escalation before submission happens. A reviewer looking only at a final summary cannot meaningfully approve a consequential action.

Test controls under failure conditions, not just normal task completion, and record the test case, result, reviewer, and decision so approval can be revisited when the agent, instructions, or permissions change. A control that worked once is not evidence it will work on different inputs.

Who should decide that the evidence is sufficient?

Three roles carry distinct responsibilities. The business owner defines the outcome and acceptable risk. Security, legal, or risk functions challenge the control design. An accountable executive or board committee approves deployment for high-consequence actions. Collapse all three into one person and the review becomes theater.

Give an independent control function the authority to delay, restrict, or stop deployment when evidence falls short. SiliconANGLE argues for exactly this: independent oversight with enforceable authority, including the power to require remediation, restrict activity, or halt high-risk use—and for independent AI experts to be able to examine evidence produced by vendors ².

Keep vendor evidence and customer evidence separate. Vendor testing can inform a decision, but the company still needs evidence about its own prompts, tools, data, permissions, destinations, and review process. A vendor's claim that its agent is safe in general says nothing about whether a specific deployment is safe in particular ².

Document the approver, the evidence threshold, permitted actions, escalation conditions, review date, and stop authority. If no person or body owns these decisions, accountability is already unresolved before the agent takes its first action.

What accountability applies when an agent acts for the company?

The agent is an instrument of the company's process, not the accountable decision-maker. A company should always be able to name who authorized the deployment, who approved the action class, and who had the authority to stop it. If those names aren't available, the company has deployed an unaccountable actor.

Keep an action record containing the agent version or configuration, instructions, tools used, destination, proposed action, human approvals, final result, and any escalation. The record supports investigation; it does not, by itself, prevent harm. Logging is necessary, not sufficient.

Define incident handling before deployment: pause the relevant capability, preserve evidence, notify the responsible owner, assess whether permissions or review thresholds need to change. Companies that write incident response after the incident spend their first critical hours figuring out who's in charge.

The reported visa-application account shows why responsibility can't wait for certainty about the technical cause. The available report says the applications were incomplete and unprocessed, but it names no controls or decision owners ¹. A company facing a similar event will need to answer those questions immediately—so the records and decision rights need to exist beforehand.

What should a company do before allowing consequential submissions?

Inventory every action the agent may take and classify it by consequence, externality, and reversibility. Treat form submission and external communication as separate permissions from drafting or retrieval—a system that can draft a visa application is not the same system as one that can submit it.

Write a deployment-specific control document: allowed destinations, prohibited actions, approval gates, escalation triggers, evidence requirements, stop authority. Don't approve a broad agent capability when the business need is a narrow workflow. Narrower permissions make the evidence question easier to answer.

Run boundary tests covering incomplete information, conflicting instructions, unapproved destinations, and attempted submission without required approval. Preserve the results as part of the approval record—these tests should be designed to make the agent fail, not to confirm that it works.

Put an independent reviewer in front of the evidence, with confirmed authority to restrict or stop the activity, in line with SiliconANGLE's emphasis on independent oversight and enforceable authority ².

Start with a limited deployment whose permissions match the evidence actually in hand. Expand only when new evidence addresses a specific boundary, failure mode, or operating condition. Default to expansion through demonstrated containment, not trust through demonstrated capability ².

Frequently asked questions

What evidence should companies require before deploying an AI agent?

Require evidence tied to the exact deployment: its tools, instructions, data, destinations, permissions and human review. A successful demonstration alone does not establish that the system will stay within deployment limits. ²

Should an AI agent be allowed to submit official forms?

Only if the company has explicitly approved that action, tested the relevant boundaries and defined an escalation or human approval point. The reported visa applications were incomplete and not processed, but the available account does not identify the controls that applied. ¹

Who should approve an AI agent's high-risk actions?

The business owner should define the use case, while an independent security, legal or risk function should challenge the evidence. For high-risk activity, the control function should have authority to require remediation, restrict the activity or stop it when evidence is insufficient. ²

What is the difference between agent capability and agent authorization?

Capability describes what an agent can do; authorization describes what it is permitted to do in a particular deployment. SiliconANGLE's analysis supports treating a strong demonstration as insufficient evidence that the agent will remain within authorized limits. ²