An Outside AI Coworker Wants Access. Verify Its Identity, Then Decide Its Rights.

AI Coworker Identity Verification Is Now a Business Question

On November 10, the Linux Foundation welcomed Agent Name Service (ANS), a proposed open way to name, discover, and verify an AI coworker against a domain its organization controls. The immediate business question is not whether every small company should publish a machine-readable identity tomorrow. It is what your company will do when a supplier's or customer's AI coworker shows up asking for access.

Imagine a distributor's purchasing role contacts your sales inbox: “I represent North Coast Foods; please confirm our pricing and reserve 40 cases.” A persuasive message, a familiar company name, and a polished profile are not evidence that the requester belongs to that customer. Even a valid domain-bound identity only establishes a particular identity relationship; it does not prove that the customer authorized this order, that the role may see contract prices, or that inventory should be committed.

ANS is important precisely because it makes the first question more tractable. Its published specifications describe domain control, certificates, registration status, DNS discovery, transparency, and peer authentication. The project documentation also says those specifications are drafts under active development. Early directory integrations do not mean every business system already verifies them. The operating question for a small business is how to use an identity signal without turning discovery into automatic trust.

This is different from identifying a coworker inside your own company. Internal work needs a traceable chain from the person who requested a task to the role that acted, as explained in our guide to delegated AI coworker identity. An external caller adds another boundary: before asking what it may do, you must establish which outside organization and role you are actually speaking with.

Discovery, Authentication, and Authorization Are Different Gates

Think about how you handle a new human vendor representative. A company website helps you find a contact. A verified work email and a callback to a known number help establish who is communicating. Neither entitles that person to see your customer list or approve a payment. An outside AI coworker needs the same separation, with stronger machine-verifiable checks when systems talk directly.

Discovery answers where a registered role says it can be reached and which protocols or endpoints it advertises. ANS describes DNS publication and associated metadata for this purpose. A directory result is a lead to investigate, not a grant of access. Attackers can create plausible names, and even an authentic organization can publish multiple roles with different duties.

Authentication answers whether the peer presenting itself now is bound to the expected registered identity, is current rather than revoked, and possesses the appropriate key. The ANS developer guidance calls for selecting trusted registration and log endpoints, checking status and possession, and testing revocation and certificate rotation. A screenshot of an identity badge or a copied profile cannot substitute for that live check.

Authorization is your own decision about what this specific verified identity may read or change for this specific customer and task. A peer may be genuinely operated by a distributor yet have no mandate to negotiate price or reserve stock. The ANS project itself distinguishes identity from application policy: registration does not automatically connect a role to every directory or prove its behavior is safe. Your own system must enforce the result.

There is also a fourth question: task provenance. Did the named customer authorize the particular request? A domain-bound role identity says who is speaking, not whether an employee approved a purchase on Tuesday. For financial commitments or disclosure of account-specific data, require a separate customer mandate or a familiar authenticated workflow. Keep that mandate tied to an order, account, ceiling, and expiration rather than relying on a generic “trusted partner” tag.

What good and bad look like in a wholesale order

Bad: A message arrives from orders-northcoast.example, a look-alike domain. The purchasing role displays a logo and a “verified” badge in its own message. Your sales Teammate accepts the badge at face value, sends the customer's discounted price sheet, and reserves inventory. The log says the request was processed, but cannot show a verified identity, a matching customer account, or an approved purchase mandate. Reversing a reservation does not undo the data disclosure.

Better: Your sales Teammate treats the message as untrusted inbound data. It checks the exact domain from the established customer record rather than a URL supplied by the requester, validates the peer through a supported verifier, checks its current status, and matches the role to the customer account. It can return a public catalog answer if policy allows. For contract pricing it uses the account-specific access rule; for a reservation it requires the authenticated purchase request or a named human approval. The reply records which gate passed and which remained closed.

That example does not assume ANS is universally deployed. If your partner and your systems cannot perform an interoperable live verification today, use existing customer authentication, a previously verified contact route, and a human callback. Do not invent a verification result just to avoid a slower handoff. “Identity unverified; reservation pending” is a useful operational status, not a failed demonstration.

A Verified Name Does Not Prove the Work Is Safe

Domain-based identity improves the answer to “who claims this role?” but cannot settle all the ways an interaction can go wrong. The expected domain might be compromised. A legitimate role might be configured too broadly. A valid customer might request something outside its contract. An identity record might be current at the start of a long task and revoked before the final write.

That is why admission must be continuous at consequential boundaries rather than a one-time registration ceremony. Recheck identity status when a conversation crosses from public information to private data or from a quote to an order. Bind permissions to the role and account, not merely the organization name. If verification evidence is unavailable, stop the sensitive action and preserve the request for review instead of silently treating the last good result as permanent.

The ANS documentation describes optional additional identity proofs and a separate authentication layer. Those are useful mechanisms, but businesses should be careful with the word “verified.” Verified against which trust root? For which version and domain? Is the certificate still valid? Did your system check it itself, or did the caller merely assert it had been checked? A badge that cannot answer these questions is presentation, not enforcement.

Nor does a signed metadata digest prove the software running remotely is safe. The project's own description is explicit that sealed metadata does not attest the code executing on a remote machine. You still need source-level access controls, limits on what the peer can request, logging of actions and outcomes, and a way to suspend the relationship. For connected systems, apply the same data-access rule at every route; otherwise a denied sales endpoint can be bypassed through a second connector.

This is a trust architecture problem rather than a branding problem. The system should be unable to disclose the wrong account's prices or place an order above a ceiling even if a convincing message reaches the model. Identity evidence narrows uncertainty about the caller. Structural rules constrain the action after that evidence is considered. Neither replaces the other.

Build a Small-Business External Coworker Admission Policy

You do not need to wait for every vendor to adopt one identity standard. Start with the business decisions your existing integrations already make and add identity checks where they change the outcome. The following procedure works for a customer portal, purchasing inbox, or partner API, with or without ANS support.

1. List the outside routes. Identify every inbound address, form, API, shared channel, and webhook where a customer's or supplier's AI coworker might request work. Note which route can return public information, disclose account data, or change a system of record. A website inquiry and a purchase-order endpoint should not inherit the same rights.
2. Define the expected organization independently. Store the customer's domain, account identifier, and approved contact or registration source from your onboarding record. Do not derive that expected identity from a newly arrived message or a link inside it. Similar-looking domains should trigger review, not fuzzy matching.
3. Verify the live peer when your stack supports it. Choose the registration authority and trust roots your verifier accepts. Check the claimed domain, certificate or key possession, registration status, version, and revocation evidence under the applicable protocol. Record when the check happened. If you cannot verify the claim, keep the request in a public-information or human-review lane.
4. Map identity to a narrow role. Separate a catalog reader from a purchasing representative and a billing administrator. Give each role an explicit account scope, allowed records, operations, and limits. A valid domain should never become a wildcard over every application connected to your Teammate.
5. Require a transaction mandate for commitments. For a price exception, reservation, refund, or purchase, identify the authorized customer, order, maximum amount or quantity, expiry, and approval source. Authenticate that mandate through a customer-controlled route. Treat the outside AI coworker as the messenger unless the customer has explicitly delegated that transaction authority.
6. Test refusal and recovery. Send a request from the right domain but the wrong role, then one from a look-alike domain, then a valid role with an expired mandate. Each should fail safely. Also test an unavailable verifier: the system should preserve the work and ask a person, not disclose data because a network lookup timed out.
7. Record and review the decision. Keep the asserted identity, verification result, policy rule, requested action, approval reference, connected-system response, and final outcome together. Review denials as well as approvals. If a trusted partner rotates a certificate or revokes a role, know who updates the mapping and who retests it.

For a small team, the first implementation can be deliberately modest. A public-information lane, an authenticated-account lane, and a human-approved transaction lane cover much of the practical risk. The complexity belongs in the gates between them. Adding an identity registry without defining those gates merely gives an overpowered integration a nicer name.

An operator should be able to answer three questions from the record after the fact: Which outside role contacted us? Which independent evidence did we check at the moment of action? Why was this specific operation allowed for this customer? If the third answer is “because the first two looked fine,” the policy is incomplete. Keep the human decision at the seam where a business commitment changes, and allow the AI coworker to do the preparation and evidence gathering around it.

FAQ

Q: What is AI coworker identity verification? A: It is the process of checking that a communicating AI coworker is bound to the organization and role it claims, using evidence such as domain control, current registration, and key possession. It does not by itself grant access to your data or authority to act for a customer.

Q: Does Agent Name Service make every external AI coworker trustworthy? A: No. ANS is a developing standard for registration, discovery, and verifiable identity, not a certification of safe behavior. Your application must implement verification and make its own authorization decisions. Support varies by integration; do not assume a directory listing means your systems enforce it.

Q: Can a verified customer AI coworker see all of that customer's data? A: No. Scope access to the authenticated account, the role, and the purpose of the request. A purchasing role might see its own open orders but not billing details, employee records, or another customer's negotiated prices. Recheck the policy at the data source, not just in a chat instruction.

Q: What if a supplier's AI coworker cannot present a verifiable identity? A: Keep the request in a restricted lane. You can provide public information, route it through an existing authenticated portal, or confirm through a known human contact. Do not treat a claimed badge, display name, or link in the inbound message as proof of authority.

Q: How is external identity different from a permission to buy? A: Identity identifies the party communicating. A purchase mandate authorizes a specific transaction within limits and for a defined period. A real customer may use a real AI coworker to ask for something that nobody authorized; both checks are needed before a binding order.

Q: When should identity be checked again? A: Check before sensitive disclosure or a consequential write, and after a material handoff or long delay. An expired registration, revoked key, changed role, or unavailable verification service should pause the sensitive step and produce a reviewable record rather than fall through to access.

If you want AI coworkers to prepare partner work while keeping identity checks, customer-specific permissions, and human decisions at the right seams, explore Associates AI Teammates and choose a plan. The platform gives your team a way to configure persistent Teammates on agent servers with clear roles and controlled access.