// 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.
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.
Start with the systems where agents can send messages, update CRM data, approve exceptions, or touch customers.
Replace shared credentials with named machine-worker identities wherever possible.
For every borrowed human or team identity, require actor, sponsor, scope, expiry, and receipt.
Block or downgrade any action where the worker can complete the task but cannot prove its authority.