# AI agents shouldn’t grade their own work > Source: > Published: 2026-11-09 11:00:00+00:00 On July 16, [Hugging Face disclosed](https://huggingface.co/blog/security-incident-july-2026) that an autonomous agent system had breached part of its production infrastructure. Five days later, [OpenAI identified](https://openai.com/index/hugging-face-model-evaluation-security-incident/) its own models as responsible. Its subsequent investigation described agents operating under reduced safeguards, exploiting flaws in shared infrastructure, and reaching the internet through a package-management service. They [exchanged discoveries on an improvised message board](https://www.engadget.com/2231393/openai-agents-shared-security-exploits-with-each-other-via-message-board/) and coordinated further attacks. Likewise, on July 30, [Anthropic reported](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals) three incidents across six of 141,006 evaluation runs reviewed. Models had reached real organizations through environments mistakenly believed to be isolated. In one incident, a malicious software package was downloaded and ran on 15 real systems. In August, [Meta confirmed](https://www.bleepingcomputer.com/news/security/meta-ai-model-hacked-a-company-during-misconfigured-cyber-test/) to Reuters and other outlets that a misconfigured evaluation environment had allowed one of its models to reach the internet and exploit a third-party service. In September, an OpenAI agent [bypassed network restrictions](https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot) by sending questions through internet address lookups. Monitoring raised an alert, but the run did not stop automatically as expected. Staff stopped it roughly two and a half hours after the alert. The concern extends to ordinary tasks. In an [October 9 report](https://www.anthropic.com/research/investigating-unintended-model-actions), Anthropic described models submitting real forms when they should have stopped beforehand or used practice copies. The company characterized the reported impact as minimal. Still, a form submission is the kind of action an enterprise agent might perform every day. The incidents discussed above involved different failures of containment, authorization and intervention. They do not establish that one completion check would have prevented them; yet, they do give CIOs a reason to examine both sides of an agent workflow. Indeed, what governance rules permit an agentic action, and what evidence allows an organization to call it complete? An agent calls a tool, the tool returns “success,” and the workflow moves on. That response might mean a request entered a queue, or it might mean a record changed. It may say nothing about whether the intended result occurred or whether this particular action produced it. That ambiguity matters when other systems act on the completion signal. For instance, an invoice could leave an exception queue while the settlement remains unconfirmed. A misleading status can conceal the need for follow-up or trigger another action. Business owners need to decide what evidence is sufficient before the workflow proceeds. Finance departments separate payment execution from reconciliation for a reason. NIST’s [separation-of-duties control, AC-5](https://csrc.nist.gov/pubs/sp/800/53/r5/final), similarly calls for documented duties and access authorizations that support their separation. Applying that discipline to AI requires more than asking the acting agent to review its own work. I developed the proposed [Common Transparency Protocol (CTP)](https://zenodo.org/records/23271007) framework to make that distinction enforceable and have filed a provisional patent application covering aspects of its architecture. CTP’s central rule is that autonomous systems performing a change cannot, by themselves, certify the action as complete. A deployment that enforces CTP places a controlled gateway between agents and the consequential operations it governs. A gateway holds the relevant execution credentials and enforces scope, authority and any required human approval before execution. Afterward, a qualified verifier obtains fresh evidence from the designated authoritative source. A qualified closure authority then accepts that evidence and records completion only when every required condition passes. These roles can be implemented in software. Human approval and review remain mandatory where the applicable policy requires them. Using a second AI agent does not itself establish independence, for its credentials, selection and controlling dependencies must meet the separation requirements. Consider a hypothetical accounts-payable workflow. A workflow instructs an agent to pay an approved invoice. Before execution, authorized policy defines the payee, amount, required approval, settlement evidence and how that evidence must connect to this specific payment attempt. The agent cannot weaken those requirements afterward. The gateway submits the authorized payment. A response saying “accepted” records the submission; it does not establish settlement. A reconciliation service, selected outside the control of the systems making the payment, uses separate read credentials to consult the authoritative payment record. It checks the amount, recipient, settlement status and transaction identifier linking the result to the governed attempt. A matching amount alone could describe an earlier payment. A separately qualified completion service acts as the closure authority. It confirms that the evidence, verifier and authority requirements are satisfied before assigning the action’s final status. Neither the agent nor the payment gateway can grant itself that status. If the effect or its attribution remains unresolved at the deadline, the original action closes as incomplete. Later evidence goes into a separate, authorized record linked to the original. The current outcome can then reflect the resolution while preserving the earlier uncertainty. A retry that could move money requires its own authorization and record. Independence is tested across the relevant systems that performed or controlled the change. Policy identifies prohibited shared credentials, administrative control or other dependencies. One prohibited overlap disqualifies the verifier or closure authority; missing evidence cannot count as a pass. Shared infrastructure is permissible only when all required separation rules remain satisfied. These controls govern completion within the deployment’s defined boundary. They do not repair an unmediated network path, guarantee that a source contains truthful data or reverse a payment already made. Containment, monitoring and incident response remain necessary. CTP connects the overall assignment to individual actions through two kinds of machine-readable records, called *envelopes*. The CTP Agentic Envelope records the objective, permissions, aggregate risk and completion rules. Action Envelopes, of which there can be zero to many, record the governed steps, including authorities, evidence and original final status. Integrity protections make any changes to protected records detectable, though they do not establish the capture of every relevant event. Therefore, the organization must also define which actions its gateway actually mediates. When an agent delegates a sub-objective to a sub agent or another agent, a linked child envelope carries the applicable constraints. Delegation may narrow permissions but cannot silently expand them. Splitting work among agents cannot reduce the safeguards required for their combined effect. An authorized mechanism applies the objective’s completion rules to the current outcomes of its subordinate actions, including later authorized resolutions. The coordinating agent cannot override those rules with its own success assertion. This keeps accountability attached to the assignment as work passes between agents. Start with one bounded workflow and an authoritative system that can supply useful evidence. For a payment pilot, the finance process owner should define completion and acceptable exceptions. The CIO’s team should implement the integrations, and the CISO should assess the sufficient separation of execution, verification and closure events. Internal audit should review whether the resulting records support reconstruction. Agree on the decision criteria before the pilot begins. Measure verification delay, cost per action, the share of actions left incomplete, and human review effort. Test delayed responses, duplicate requests, stale evidence and attempted self-certification. Expansion should depend on meeting agreed service limits while refusing completion whenever mandatory evidence or authority is missing. The pilot should also establish what happens operationally when an action remains incomplete. Assign an owner to investigate it, define which dependent actions must wait, and specify when human intervention is required. Recording uncertainty is useful only if the organization has a practical way to resolve it without blindly repeating the original action. Ask vendors to demonstrate where execution credentials reside, who selects the verifier, and which component can record completion. Request a demonstration of an unresolved action and its later reconciliation. An architecture diagram or a dashboard labeled “success” is insufficient evidence of these capabilities. We tested a CTP proof of concept across seven internal scenarios. These included successful completion, incomplete and denied outcomes, tampering and VistA scenarios with and without audit evidence. All seven scenarios produced the expected results. These demonstrations provide initial evidence of CTP’s viability within the tested scope. Broader testing is still needed to assess production-scale reliability, performance and operating costs. Before giving an agent more authority, ask what evidence your organization will require when it says the work is done, and who has the right to accept that evidence. Those decisions belong in the system’s design.