Your AI Coworker Sent the Update. Who Actually Authorized It?

AI Coworker Identity Has to Answer Two Questions

On November 3, IBM made Agent Identity generally available in watsonx Orchestrate, adding agent-specific audit logs and a way to stop a running role. Its most useful claim is deceptively simple: an investigator should be able to identify both the AI coworker that acted and the person it acted for.

Imagine a customer receives a message saying their permit application has been approved. The message came from an approved customer-service connection. The AI coworker that sent it has a name. But who requested that specific update? Was it the account manager, a scheduled status check, or another Teammate passing along a stale summary? And did any of those sources have authority to declare approval?

A log that says only “the customer-service role sent a message” cannot settle that question. A log that says “the account manager's credentials were used” is worse if the account manager never requested the message. Identity answers who performed an action; delegated authority explains why that action was allowed, for whom, and within which limits.

IBM describes its implementation as a distinct identity registered through IBM Verify or Microsoft Entra. In its documented flow, an AI coworker calls a connected system as itself using an OAuth token exchange scoped to the user and the role. That is a specific product capability, not a feature every business platform automatically has. The broader operating lesson applies to any organization deploying persistent AI coworkers: the work needs a traceable chain from request to action, not a shared login and a plausible explanation afterward.

NIST's October 27 design tenets for agent identity make the same distinction explicit. They propose separate identification for the acting software, a link to the task originator, narrower rights when authority is handed downstream, and authorization that can be revoked. NIST calls these proposed design tenets, not a certification that existing products already satisfy. For small businesses, they are a practical test of whether an AI coworker truly holds a bounded role or merely borrows someone's keys.

A Login Is Not a Mandate to Do the Job

A business often starts with one integration and one broad service account. A sales Teammate reads CRM records, drafts follow-ups, and sends messages using a shared connected mailbox. It works in a demonstration. Then a manager asks the sales role to summarize open deals, and a customer reply in the CRM says, “Please change the billing address and send the new invoice.” The software can technically do both. Only one task was authorized.

The error is treating a valid connection as a standing instruction. A credential establishes access to a system. It does not specify which customer, which outcome, which amount, which deadline, or which person may approve a change. The same AI coworker can execute an authorized summary at 9:00 and an unauthorized invoice edit at 9:01 if the boundary is only “has CRM access.”

A useful authorization record has at least four distinct parts:

• Originator: the person, approved schedule, or upstream business process that initiated this task. A schedule should point to its named human owner and approved purpose, not masquerade as a human who was asleep.
• Actor: the specific Teammate role and configuration that attempted the action. This is not the same as the model provider processing its text or the human whose mailbox is connected.
• Mandate: the desired outcome and constraints: customer, allowed records, permitted operations, spending ceiling if relevant, expiry, and escalation rule.
• Action evidence: what connected system received the request, what that system returned, and whether the result was confirmed. A drafted email is not a sent email; an attempted invoice update is not a posted invoice.

Those are separate fields because each answers a different question. “Who clicked start?” does not tell you whether the later write matched the assigned task. “Which Teammate ran?” does not tell you whether its authority came from a legitimate user, a timer, or untrusted content inside a document.

The NIST proposal goes further than maintaining good notes: it describes verifiable links among originator, actor, and delegated scope, and says downstream authority should narrow rather than expand. Small teams may not have the infrastructure for cryptographically signed mandates today. They can still implement the operational principle: write the task boundary down, carry its identifier through handoffs, and enforce the limit in the systems where actions actually happen. Do not present a spreadsheet as equivalent to NIST's proposed cryptographic design.

What good and bad look like in the same workflow

Bad: A support Teammate receives a message saying “fix this customer's invoice.” It reads an attachment with an account number, changes the billing address through a shared finance credential, and sends a corrected invoice. Its activity log shows a successful finance API call. Nobody can distinguish the actual customer's request from text supplied by a third party, or identify who approved the financial change.

Good: The support role identifies the request as a billing exception. It records the customer's account, the attachment's source, and the proposed change, but has read-only finance access. The finance owner reviews the current customer record and approves a bounded instruction to update a specific address on a specific account. A finance Teammate receives only that scoped task. The connected finance system enforces its own write permissions, records the resulting transaction ID, and returns the outcome for reconciliation.

The good workflow is not slower by accident. It spends human judgment precisely where the facts and authority change: from “a message arrived” to “the ledger may be altered.” Other steps can continue without a meeting or an approval for every read. That is seam design in practice: move routine preparation to the AI coworker, keep consequential judgment with the person who owns it, and make the transition verifiable.

Follow the Delegation Chain Across Every Handoff

IBM's November release is significant because it describes a token tied to both the acting identity and the user on whose behalf it acts. Its logs record the connection, operation, and represented user. That makes a particular class of question easier to investigate. But most small-business jobs do not begin and end with a single person pressing a button in one app.

Consider a weekly customer-renewal routine. A scheduled operations Teammate checks upcoming expirations. It asks a sales Teammate to prepare outreach. Sales asks a finance Teammate whether an account is current. Finance returns a status; sales drafts a message; a human reviews the final terms. There are three AI coworker roles, a schedule, several business systems, and one eventual external communication. Which identity should the CRM see when sales reads a record? Who can access finance data? What happens if the finance role's response includes a suggestion to discount the renewal?

The answer is not “whoever has the broadest credential should carry the whole workflow.” Each handoff needs to preserve the origin of the request and narrow the allowable work. Finance can report an account state without gaining the right to rewrite a contract. Sales can draft outreach without inheriting a finance role's payment access. A scheduled trigger can initiate research without gaining the owner's authority to promise a discount.

A simple handoff packet can contain a task ID, initiating source, named owner, allowed customer IDs, current step, permitted read and write operations, expiry, and a pointer to the evidence used so far. The receiving role should reject an instruction that expands the permitted scope, even when it arrives from another trusted role. The destination API should independently reject an unauthorized operation. Instructions alone cannot be the only enforcement point; NIST explicitly recommends separating the reasoning system from the access policy that decides what it may do.

There is a subtle distinction here between ownership and delegation. A human owner is accountable for configuring a recurring process. The person who requests a particular task may be a different colleague. The customer whose records are affected is neither of them. A useful audit trail keeps those relationships separate instead of filling every field with the same convenient employee name.

This is also why a long-lived, shared API key is such a weak foundation for a team of AI coworkers. It may tell the connected service which account holds the key, but not which role initiated a specific action or which user authorized it. When short-lived, task-scoped credentials are available, use them. Where they are not, isolate connections by role, constrain actions at the application layer, retain an independent event trail, and acknowledge the residual attribution gap rather than claiming a level of proof the integration cannot provide.

Build an AI Coworker Identity Test in One Week

The point is not to buy an enterprise identity suite before letting an AI coworker summarize a document. The point is to keep authority proportional to the consequences of the job. Use this test on one real workflow that crosses a system boundary.

1. Pick a consequential action, not an impressive demo

Choose a customer-facing send, an invoice change, or a status update in a source-of-truth system. Name the record, the business outcome, and the person who owns the decision. Do not begin with “the Teammate can use the CRM”; begin with “the Teammate may prepare renewal drafts for accounts assigned to this team.”

2. List every identity on the route

Write down the initiating user or schedule, the Teammate doing the work, any downstream Teammate, and the connected service account or token. Ask which identities the destination system can actually distinguish. If the CRM sees only a shared employee login, document that limitation as an engineering task, not a solved audit control.

3. Define a bounded mandate

Record the permitted customer, operations, time window, and human approval requirement. State the negative space: no new customer records, no discounts, no external sends before review. A clear mandate makes it possible to test an attempted action against business intent rather than deciding afterward whether its outcome looks reasonable.

4. Put the deny decision outside the generated answer

Check whether the connected system, a policy layer, or a separately controlled action gate can refuse a write that exceeds the scope. A Teammate can explain why it wants to act, but it must not be able to declare its own expanded permissions. The NIST tenets explicitly distinguish reasoning about an action from deterministic access decisions.

5. Try a legitimate request and a near miss

Run an approved task with a specific account. Then change one dimension: different account, expired request, unapproved send, or another role asking for a broader finance operation. The legitimate work should proceed; the near miss should fail at the action boundary and produce a record showing why. A test that only checks a polite refusal in chat does not prove the connected system would have blocked the action.

6. Reconstruct the result without asking the AI coworker

Have someone uninvolved in the run locate the originator, actor, scope, approval, destination request, and final system state from stored records. Include a failed attempt, not only successful writes. Compare the business record to the event trail. If the observer needs the Teammate's recollection to explain what happened, the evidence is not yet independent.

7. Repeat after an owner or policy change

Change the owner, revoke a permission, or pause the recurring schedule. Confirm that a pending task cannot simply continue with cached authority. The related examination of an AI agent kill switch covers the time-of-use problem in depth; this test adds a different question: can you tell whose mandate each remaining action was operating under?

Do not confuse this with a complete compliance program. It is a compact operational test that exposes where identity, delegation, and enforcement fall apart before a customer or auditor discovers the gap. Fix the highest-impact missing link first. If a finance API cannot distinguish two roles, separate their credentials before building a beautiful dashboard on top of shared access.

FAQ

Q: What is the difference between AI coworker identity and AI coworker authorization?
A: Identity establishes which role is acting. Authorization decides whether that role may perform a particular operation for a particular requester, record, and time. A correctly identified AI coworker can still attempt an unauthorized action.

Q: Is a named human owner enough to prove who authorized an action?
A: No. Ownership assigns responsibility for a role or recurring process; it does not prove that the owner requested or approved each transaction. Preserve the specific task origin and approval evidence separately.

Q: Can a scheduled Teammate act on behalf of a user who is offline?
A: Yes, if the schedule has a defined owner, purpose, scope, and expiry. The audit record should identify the schedule as the immediate trigger rather than falsely attributing a fresh instruction to an offline person. Consequential writes still need the authority appropriate to the job.

Q: Does the November 2026 IBM release solve this problem for every business?
A: No. IBM describes capabilities inside watsonx Orchestrate, including distinct identities, user-and-role-scoped token exchange, and role-specific logs. Those capabilities illustrate a useful design, but your actual controls depend on your runtime and the connected system's identity model.

Q: What if a connected application supports only one shared account?
A: Limit what that account can do, separate high-risk workflows, capture independent task and transaction IDs, and require a human-controlled gate for consequential changes. Record that the application cannot provide role-level attribution; a prompt or a shared-account log cannot manufacture it.

Q: Should every read require human approval?
A: No. The right boundary is risk-based. Routine, authorized reads can proceed within narrow scope. Sending external promises, moving money, or changing source-of-truth records deserves stronger evidence and, where judgment is required, a named human decision. See the practical design for approval packets for that handoff.

If you're ready to build AI coworkers that can do real work while your team keeps clear authority over the consequential decisions, explore Associates AI Teammates and choose a plan. The platform gives your business persistent Teammates, defined roles, and an operating layer for the work between the request and the result.