Your AI Coworker Passed a Test. That Is Not Permission to Run Your Business.

A Verification Stamp Is Evidence, Not a Master Key

On October 14, 2026, Workday introduced Agent Passport in early access: a signed record of what an AI system was tested for, who tested it, and against which standard. That is a useful advance. It is not a universal clearance to give an AI coworker your payroll records, customer inbox, or purchasing account.

Workday's announcement pairs independent assessment with named business and technical owners. It says the first cohort is testing real HR and finance systems, while general availability is planned for the end of the year. That distinction matters: this is an early-access approach to portable testing evidence, not proof that every outside AI coworker can already present a universally accepted passport.

A test answers a bounded question. Was this version evaluated against a stated failure mode, using a particular method and set of conditions? Deployment answers a different question. Should this role, in this business, with these permissions, be allowed to act on this data today? Confusing the two turns a useful assurance record into a permission shortcut.

For a small business, the practical goal is not to recreate a corporate certification program. It is to make the handoff from tested behavior to authorized work explicit and reviewable. Keep the evidence, but write down the decision it supports—and the decisions it does not.

What AI Coworker Verification Evidence Actually Proves

Workday describes a stamp as a record of an independent test for a specific risk against a published standard. Its first security assessments include adversarial testing by Cisco AI Defense; planned integrations with other assessors are not the same as completed assessments today. The company also distinguishes security tests from governance assessments concerning oversight, data handling, and audit trails. Passing one axis cannot substitute for the other.

A useful evidence record has at least five parts: the system and configuration tested, the risk evaluated, the test method and assessor, the result and unresolved exceptions, and the date or version to which it applies. An unqualified badge that says “safe” omits the information an operator needs. The more consequential the action, the less acceptable that omission becomes.

Suppose a scheduling AI coworker passes an adversarial test showing it resists a class of malicious text in calendar invites. That evidence says something meaningful about the tested configuration. It does not establish that the same coworker may read employee medical notes, change hourly rates, or send binding offers to job candidates. Nor does it show that the configuration still behaves the same after a new connector, model, Skill, or policy source is added.

IBM's October 14 watsonx.governance update illustrates the other half of the problem. IBM describes detecting assets and changes, linking evaluation metrics to defined controls, and synchronizing those controls with runtime enforcement in its own product environment. Its announcement is a vendor description, not an independent finding that such controls eliminate risk. The important operating distinction is general: an assessment records evidence; a control determines what is allowed at the moment an action is attempted.

What bad looks like

A store owner sees a “verified” badge on a customer-service AI coworker and connects the shared administrator account for the store, refunds, and email. The assessor tested responses to hostile support messages in a demonstration environment. The badge did not cover the live refund connector or a policy permitting refunds above a certain amount. The coworker sends an incorrect refund, and no one can identify whether the failing component was the model, the connector, or the broad administrator permission.

Nothing about the original test necessarily was false. The owner treated a narrow claim about behavior as a broad grant of authority. The failure happened at the seam between evidence and deployment.

What good looks like

The same owner records the precise test, checks which version and tools were included, and grants the AI coworker read access to order status plus permission to draft a refund recommendation. A human authorizes the actual refund through a separate account. The business owner is responsible for deciding which customer outcomes the role may handle; a technical owner maintains the connector and can revoke access. When the refund workflow changes, the approval and relevant tests are reviewed again.

This does not require blind trust in a certificate, or universal distrust of testing. It uses a test for the question it answered and a separate permission system for the question it could not answer.

Turn a Test Result Into a Deployment Decision

Treat the decision as a small contract between the business, the AI coworker, and the systems it touches. A one-page record should state the job, available data, permitted actions, prohibited actions, approval points, owner, evidence, and change triggers. You can start with a spreadsheet and a restricted credential rather than buying a governance suite.

First, define the role in terms of outcomes. “Prepare a daily list of overdue customer requests and draft replies” is testable. “Help with operations” is not. State whose time it saves and how you will know that it did. The role description is an intent-engineering artifact: it encodes what success means and what must remain human judgment.

Second, separate read, recommend, and write authority. Reading a supplier catalog is different from recommending a new vendor; recommending a vendor is different from placing an order. The same model can carry out all three, but they are different business permissions. A good design permits the narrowest useful action by default and builds a deliberate seam before money, personnel decisions, deletion, or external commitments.

Third, map each permission to the specific evidence that bears on it. A prompt-injection test may be relevant to an AI coworker reading untrusted email; it is not a financial authorization test. A finance accuracy evaluation may support a recommendation workflow; it does not prove the right bank account was selected for a transfer. Write “not tested” when the evidence does not cover a risk. Unknown scope should be visible, not silently interpreted as a pass.

Fourth, make the approval enforceable outside the AI coworker's own prose. A message saying “ask before you refund” does not stop a connector that accepts refund calls from the same credential. Use separate credentials, restricted operations, transaction limits, and a human-controlled approval path where the consequence warrants it. These structural boundaries keep holding even if the underlying model has a bad day.

Fifth, retain a compact decision record. Record who approved the deployment, the tested configuration identifier, the connected tools, allowed actions, known exceptions, the date, and a rollback owner. Avoid storing sensitive customer content in the governance log just to prove governance exists. The log should make a decision reconstructable without becoming another uncontrolled copy of private data.

This is the distinction between a tool and an AI coworker in practice. A tool returns an answer in one session. A persistent coworker has a durable role, access that survives sessions, and responsibilities that change as the business changes. The verification process must follow that role over time rather than stopping at a launch-day screenshot.

Verification Expires When the Job Changes

A signed test result may remain an accurate statement about what was tested. Its relevance to today's deployment can still expire. Change the model provider, system instructions, data source, connector permissions, or the kind of action the coworker can take, and the original test may no longer cover the current risk. Even without a configuration edit, a new business policy may change what counts as a correct decision.

The right response is not to rerun every imaginable test after every typo fix. Classify changes by which boundary they could affect. A correction to an internal description might need a quick review; enabling access to compensation data needs a new privacy and authorization review. Replacing a read-only tool with a write-capable one changes the threat surface even if the prompt is identical.

A simple rule: if a change affects who, what data, which action, which model or instruction set, or which human approval, the owner must decide whether existing evidence still applies. Keep the affected action disabled while a consequential gap remains unresolved. This is especially important for always-on work: a Teammate should be able to pause, present the missing evidence to its owner, and resume only after the boundary is restored.

Workday's named owners are a useful signal here. Its announcement says a business owner and a technical owner are assigned to each system, with Agent Owners expected to be generally available later in October. Those roles answer different questions. The business owner decides whether a job and its consequences belong in the role. The technical owner can identify the deployed version, change access, investigate logs, and restore a prior configuration. At a small company, one person may fill both roles, but the two decisions should not collapse into an unexplained click.

IBM's change discovery and control-to-runtime linkage point in the same direction. Finding a changed system is only the beginning. Someone must judge whether the existing tests apply, and a technical boundary must enforce the outcome. A dashboard that detects a new connector but leaves the old permissions untouched has observed a risk, not contained it.

This is also why an AI coworker's lifecycle needs an offboarding plan. A verified role can cease to be necessary. When it does, remove its access, cancel pending jobs, preserve required audit evidence, and identify who takes over incomplete work. Test evidence should never become a reason to keep an unused credential alive.

A Seven-Step Verification Gate for a Small Business

Use this before your first production deployment and whenever a meaningful boundary changes. The output is an explicit authorization, not a ceremonial “approved” checkbox.

1. Name the job and owner. Write one outcome the AI coworker is accountable for, one business owner, and one technical owner or backup. If no one can name the owner, keep the role read-only.

2. Inventory the proposed access. List each system, the exact records available, and whether the coworker can read, draft, send, edit, delete, or spend. Include scheduled and background work, not only interactive chat.

3. Collect evidence by risk. Link each test to the version, tools, test environment, assessor, method, result, and exceptions. Distinguish independent assessment from a vendor's own statement. If there is no relevant test, say so and reduce the proposed authority.

4. Run a local scenario. Use synthetic or appropriately protected records to check the job in your own workflow. Include one ordinary case, one ambiguous case that must pause, and one forbidden action that the system must actually prevent. Observe tool calls and resulting state, not only the final message.

5. Enforce the narrow grant. Issue role-specific credentials, limit connector operations, and put human authorization before consequential actions. Test a denied call directly. A written promise is not a substitute for a rejected API request.

6. Record approval and recovery. Have the owner sign off on the exact scope and known gaps. Test who can stop pending work, revoke credentials, correct an error, and communicate an affected customer outcome. Link that recovery procedure to the deployment record.

7. Set retest triggers. Require review when the model, instructions, retrieval source, Skills, connectors, permissions, or business policy materially change. Monitor real outcomes and complaints between reviews; a passing launch test is a baseline, not a perpetual warranty.

The gate is intentionally small. A local business might use one shared document, a handful of repeatable scenarios, and a restricted service account. The value is not paperwork volume. It is the ability to answer, on a difficult day, “What exactly did we authorize, what was tested, and what changed?”

FAQ

Q: What is AI coworker verification evidence?

A: It is an inspectable record of a test or assessment against a defined risk and configuration. Useful evidence identifies the version, method, assessor, result, and limits. It does not itself grant access to business systems.

Q: Does a security stamp mean an AI coworker is safe to deploy?

A: No. A stamp can support a decision about the risk it tested. The operator still has to evaluate the intended role, local data, permissions, approval checkpoints, and recovery path. “Tested against prompt injection” is not the same as “authorized to issue refunds.”

Q: Can a small business use this approach without a formal certification?

A: Yes. Maintain a versioned test record and a separate one-page permission decision. Run realistic local scenarios, enforce narrow credentials, and name a human owner. Independent assessment is valuable for higher-risk work but does not replace the local decision.

Q: When should we retest an AI coworker?

A: Review the evidence when a change could affect its risk: a different model, instructions, data source, Skill, connector, permission, or governing business policy. Retest the affected scenarios before expanding consequential authority, and monitor production outcomes in between.

Q: Who is responsible if a verified coworker makes a mistake?

A: The accountable business owner owns the decision to use it for that job; the technical owner is responsible for configuration, access, investigation, and recovery within their remit. Verification helps reconstruct a failure. It does not transfer business accountability to a badge or remove the need for a human correction path.

Associates AI Teammates gives your business a way to configure persistent AI coworkers with defined roles, Skills, and operating boundaries on agent servers. View pricing and choose a plan when you're ready to build a team whose permissions match the work it actually does.