// MACHINE-WORKER MANAGEMENT · TRUST DENSITY · June 20, 2026

Machine-Worker Management Needs Identity Boundaries Before Agents Borrow Human Authority

If an agent can borrow a human identity, the control plane must show exactly whose authority it is spending.

WhatBounded identity

Identity boundaries define which machine workers may act under which operational identity, what they may do there, and when the borrowed authority expires.

WhyAuthority leaks

Agents can inherit permissions from tools, teammates, aliases, and integrations faster than managers can see which identity is being used for which promise.

ConsequenceTraceable delegation

Heads of Growth get machine-worker speed without confusing customers, reps, managers, or auditors about who actually took responsibility.

Machine workers should not hide inside human accounts.

The fastest way to make agents useful is to let them use the systems people already use. That is also the fastest way to erase accountability. A rep account can send a note. A manager login can approve a discount. A support alias can promise a fix. A generic automation user can rewrite half the operating record.

The issue is not whether the task was correct. The issue is whether the company can reconstruct the authority chain after the task changes customer reality.

Named humanA person is not a proxy.

If an agent sends as a human, the message must show delegated scope, source evidence, and whether the person reviewed the action before it went out.

Team aliasA queue is not ownership.

Messages from sales@, success@, or ops@ need a machine-worker receipt so the team can see which worker acted and which policy it followed.

Shared loginConvenience is not governance.

Shared credentials turn accountability into archaeology. Replace them with named agent identities, scoped tokens, and visible delegation records.

Automation userA bot is not a blank check.

The generic automation account should not become a permission landfill. Every workflow needs a named sponsor and a bounded action set.

Identity boundaries are how delegation survives automation.

Human orgs run on delegated authority: who may speak for sales, who may approve spend, who may promise delivery, who may edit revenue truth. Agentic orgs need the same thing, but machine-readable. The worker's identity should answer five questions before it acts: who is the machine worker, whose authority is it using, what can it change, how long is that authority valid, and what evidence will be left behind?

That turns identity from a login problem into an operating contract.

Actor

Name the actual machine worker and workflow, not just the tool or integration that executed the action.

Sponsor

Name the human, team, policy, or control-plane rule that delegated authority for this class of work.

Scope

Define allowed systems, audiences, fields, claims, spend limits, approval classes, and customer contexts.

Expiry

Set when the delegation ends: time window, campaign end, account stage, policy version, confidence drop, or exception count.

Receipt

Attach a visible record: source evidence, prompt or rule version, approval state, changed object, rollback path, and reviewer.

Example: the agent emails from a rep's inbox.

A prospect asks a pricing question. The agent finds an approved answer and sends from the account executive's email. Without an identity boundary, the buyer believes the AE personally committed. With one, the note is either visibly drafted for review or sent under a delegated assistant identity with the exact policy and source attached.

Example: the agent approves a campaign exception.

A growth worker grants a nurture-flow exception for a strategic account because a manager approved similar cases last week. That is not authority. The boundary forces a fresh sponsor, current scope, and expiry before the exception changes the customer path.

The more human an agent appears, the stricter its identity boundary must be.
TrackBorrowed actions

Count every action where a machine worker used a human name, team alias, shared integration, or inherited permission.

TrackUnclear sponsor rate

Measure actions where the worker completed the task but the authority source cannot be named in one sentence.

TrackIdentity rollback time

Measure how long it takes to identify, explain, and reverse an autonomous action after a customer or operator disputes it.

Do not wait for an audit to discover who your agents are.

Most teams notice identity too late: when a customer asks who promised something, a rep disagrees with a sent message, finance challenges an approval, or security finds a shared token. By then the company is not debating automation. It is debating trust.

Good machine-worker management makes the boundary visible before the work scales. Agents can still move fast. They just cannot borrow authority invisibly.

Step 1Inventory identities

List every human account, alias, integration user, and automation account that agents can use today.

Step 2Classify authority

Separate draft, send, approve, edit, delete, spend, promise, and escalate permissions.

Step 3Add sponsor rules

Require every borrowed identity to name a sponsor, scope, expiry, and receipt before execution.

Step 4Test disputes

Pick three recent autonomous actions and prove you can explain who acted, under whose authority, and how to reverse it.

Concrete takeaway

Do not let autonomous workers act through human or shared identities without a visible delegation contract.