Replace the label with a bounded task
A platform described as agentic may propose changes, execute workflows or coordinate tools, but the label does not establish what it can safely do. An evaluation should begin with a concrete task, its permitted scope, the approval required and the evidence of completion. A persuasive conversation or demonstration is not proof that the system binds an approval to the exact tenant and configuration change the reviewer intended.
This article proposes defensive acceptance criteria for an authentication platform. It does not claim that EmailAuth implements autonomous execution, tool integrations or any approval mechanism. No agent was connected to production, credential created or configuration changed. Official documentation cited here illustrates specific control mechanisms in other systems; the platform under evaluation must supply its own supported behavior and authorized test evidence.
Define the task and its authority boundary
Specify the intended outcome in operational terms, such as preparing a policy recommendation, producing an exact DNS diff or executing an already approved change in an isolated fixture environment. Separate read-only analysis from writes, publication, access changes and external communications. A system permitted to summarize reports should not infer permission to modify DNS because it believes the change would help.
Record the tenant, domain, resource type, permitted tools, input sources and prohibited actions. Include the identity under which any tool would operate and the scope that identity actually has. Azure's multitenant identity guidance supports separating identity and resource authorization. The evaluation should verify that the platform cannot substitute a different tenant merely by changing a request parameter or relying on an ambiguous display name.
Bind approval to the exact intended diff
A useful approval identifies the target, current baseline, intended change, consequences and verification plan. It should not be treated as a reusable permission for any later change that seems similar. The evaluator should ask what the system does if the proposed diff changes after approval, if another actor edits the resource or if the task is resumed with incomplete context. These are proposed requirements, not claims about a particular approval product.
GitHub's deployment-review documentation describes a concrete environment-review mechanism with approval and rejection behavior and configuration-dependent controls. It illustrates that approval systems have defined scope and constraints. It does not prove approval-to-DNS-diff binding in an authentication platform. Require the evaluated product to show exactly what the reviewer approves and how execution remains tied to that object.
Detect stale state rather than overwriting it
A plan can become unsafe when the underlying configuration changes between review and execution. The acceptance test should alter the fixture baseline after approval and observe whether the system stops, re-reads and seeks a new decision when necessary. A previously approved desired value does not authorize silently discarding another legitimate change. Retain the baseline identifier or digest used by the plan and the evidence checked immediately before execution.
Azure DNS records documentation describes Etags that can detect concurrent changes when used in supported update operations. That is a provider-specific mechanism, not a universal property of agentic tools or DNS. The evaluated platform should identify its actual concurrency control and behavior when a conflict occurs. A warning in a narrative response is not equivalent to preventing an outdated write.
Verify outcomes independently of tool confidence
A successful tool response can show that a request was accepted without proving the intended external state. Define the post-change checks needed for the task and the source of those observations. For a DNS-related fixture, that may involve supported authoritative and recursive observations with exact names, types and times. For a report workflow, it may involve retained output scope and provenance. This article does not execute either kind of check.
The platform should report partial failure and uncertainty honestly. If verification fails, the task should not be labeled complete merely because the write returned success. Recovery requires a supported plan and the necessary authority; it should not automatically introduce additional changes or external communications outside the approved scope. Retain the difference between attempted, accepted, verified and unresolved actions in the evaluation record.
Test wrong-tenant and ambiguous-target behavior
Use at least two synthetic tenants with similar labels but distinct stable identifiers and resources. Ask the evaluator to confirm that an approved action for one cannot be applied to the other. Include a case where the human-readable domain or customer name is ambiguous and a case where a tool returns a resource outside the approved scope. The safe expected outcome should be specified before the test, not rationalized after observing the system's behavior.
Do not run these tests against another customer's data or a production environment without explicit authorization. The fixtures should contain no live secrets or consequential destinations. A read-only task can still expose data if tenant binding is wrong, so the test plan must cover reads as well as writes. This manuscript provides proposed cases, not results from a real agent evaluation.
An observable-task worksheet
Create a worksheet with task definition, permitted scope, fixture tenant, starting state, proposed diff, approval reference, execution identity, tool calls allowed and verification criteria. Add expected behavior for stale state, wrong tenant, denied action, partial failure and failed verification. Record actual observations only after an authorized run, including any uncertainty about whether an action executed. Do not replace missing evidence with a model's explanation of what it intended to do.
For repeatability, retain the product version, configuration, test inputs and nonsecret output references. Separate a pass on one bounded task from a claim of general autonomous competence. A system that correctly prepares a recommendation has not thereby demonstrated safe production execution. Likewise, a successful happy-path change does not prove resistance to stale approvals or tenant confusion.
Fictional diagnosis: approval survives a changed target
A fictional evaluator approves a fixture policy change for one domain. Before execution, another authorized actor changes the baseline, and the test harness supplies a similarly named resource in a second tenant. The evaluation asks whether the platform notices both changes and stops rather than applying the old approval to the new state or target. The correct conclusion depends on actual observed behavior, not on the agent's stated confidence.
No such test was run here. The scenario contains no real domain, account or production tool action, and it is not an allegation about EmailAuth. It illustrates why approval quality must be evaluated through the relationship between the approved diff, current state and executed target. A polished explanation cannot substitute for that binding.
Report the demonstrated scope and remaining limits
A useful evaluation states exactly which tasks were tested, which controls were observed and which cases remain open. Avoid broad claims such as fully autonomous, always safe or eliminates human review based on a small fixture set. Document the human responsibilities that remain, including authorization, business judgment and response to uncertain outcomes.
The catalogue requires tested approval-to-diff binding with stale-state, wrong-tenant and failed-verification cases. That original evidence remains open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies an acceptance design and fictional exercise, not measured agent performance or permission for irreversible action.