Giving AI agents identity without letting them impersonate humans

An AI agent should act on behalf of a person without becoming that person.

That distinction is the foundation of identity in multiplayer AI. If an agent uses a founder’s API key, a shared administrator account, or a connector authorized as “the workspace,” the system may function, but it cannot answer the most basic governance question: who did what under whose authority?

The answer needs at least two identities. The delegating principal expresses intent and remains accountable for the mandate. The agent principal executes within an independently enforceable scope. External actions carry both.

The multiplayer AI product model treats agents as participants rather than features. Participants need names, roles, permissions, ownership, and history. This article describes the identity architecture underneath that product promise.

Separate requester, agent, and credential

Three concepts are often collapsed:

1. Requester: the human or system asking for an outcome.
2. Agent: the durable software principal assigned to pursue it.
3. Credential: the temporary proof presented to a specific tool.

They have different lifecycles. A requester may leave the company. An agent may be disabled or upgraded. A credential should expire in minutes. Treating all three as one bearer token creates unnecessary authority and poor auditability.

Diagram 1: the delegation chain

The audit chain preserves the delegating human, executing agent, issued capability, and external action as distinct identities.

 ┌──────────────────────┐
 │ Human: Priya         │
 │ principal H-204      │
 └──────────┬───────────┘
            │ delegates
            │ purpose="renew vendor"
            │ work=W-771, expires=Friday
            ▼
 ┌──────────────────────┐
 │ Renewals agent       │
 │ principal A-018      │
 │ role=vendor-renewal  │
 └──────────┬───────────┘
            │ requests capability for one step
            ▼
 ┌──────────────────────┐
 │ Credential broker    │
 │ evaluates policy     │
 └──────────┬───────────┘
            │ issues 5-minute, audience-bound token
            ▼
 ┌──────────────────────┐
 │ Procurement API      │
 │ action=read_contract │
 └──────────────────────┘

 Audit actor chain: H-204 → A-018 → credential C-991 → action X-440

In the interface, Priya sees “Renewals Agent is reading contract 1187 on your behalf.” An auditor sees the same chain with immutable identifiers. If the agent is disabled, Priya’s own access remains untouched.

Model an agent as a first-class principal

An agent identity should not be a label attached to a workflow. It needs durable attributes that policy can evaluate.

At minimum, the identity record should include a stable principal identifier, tenant boundary, display name, defined role, and owning team. It should record whether the agent is active, suspended, or retired, and point to the approved runtime profile and skills it can use. It should also declare the highest risk class it may handle, whether it may delegate further, and the principal that created it.

Those fields should be versioned and administered independently from prompts. Changing an instruction should not silently change who the agent is or what authority the platform associates with it. Conversely, suspending the principal should take effect even if an old worker still holds the previous prompt and plan.

The runtime profile and skills describe how the agent operates. They do not grant authority by themselves. Authorization still depends on the current delegation, work, resource, and policy.

This separation prevents a common failure: assuming that because an agent is capable of sending email, it is allowed to send this email. Capability answers “can the software perform the operation?” Authorization answers “may this principal perform it now, for this purpose?”

Make delegation explicit and bounded

A delegation is not a blanket statement that the agent works for the user. It is a signed, queryable grant with an explicit lifecycle.

The grant should identify the tenant, delegating principal, receiving agent, and work item. It should state the business purpose, resource scope, allowed actions, risk ceiling, approval rules, start time, and expiration time. It should also say whether further delegation is forbidden—which should be the default—and whether the grant is active, revoked, or expired.

Binding the delegation to a work item prevents authority from drifting into unrelated tasks. Purpose matters as well: access to customer data for resolving a support case should not authorize using the same data to build a marketing list.

The platform should retain the delegation version used for every consequential action. That gives revocation and policy changes a precise boundary: historical actions remain attributable to the grant valid at the time, while future steps must obtain authority from the current grant.

The user experience should expose these boundaries in ordinary language:

Vendor Renewal Agent may read contracts and prepare changes for this renewal until Friday. It must ask before changing commercial terms or contacting the vendor.

That sentence is not generated policy documentation. It is a projection of the same structured delegation enforced by the platform. When permission screens and runtime enforcement come from different sources, users eventually discover the discrepancy.

Evaluate authorization at the action boundary

Prompt instructions are not access control. The decision must occur in trusted code before credentials are issued or an external effect is committed.

Diagram 2: authorization before a tool call

A trusted policy boundary decides whether to allow, deny, or require approval before credentials are issued.

 Agent proposes tool action
             │
             ▼
 ┌─────────────────────────┐
 │ Normalize action        │
 │ connector + resource +  │
 │ operation + data class  │
 └────────────┬────────────┘
              ▼
 ┌─────────────────────────┐
 │ Policy decision         │
 │ agent identity          │
 │ delegation + purpose    │
 │ work state + risk       │
 │ resource attributes     │
 └──────┬──────────┬───────┘
        │          │
      allow      require approval / deny
        │          │
        ▼          ▼
 ┌────────────┐  ┌───────────────────┐
 │ Credential │  │ Explain boundary  │
 │ broker     │  │ in the work thread│
 └─────┬──────┘  └───────────────────┘
       │
       ▼
  External tool

A useful authorization decision includes more than roles. It evaluates the renewals agent as the actor, the current work-specific delegation, the proposed vendor-term update, the exact contract resource, the renewal purpose, the current work state, the proposed change in payment terms, and its risk classification.

The result should be allow, deny, or require approval, accompanied by a stable reason code and a human-readable explanation. A reason code lets product analytics distinguish missing access from policy risk. The explanation tells the user what to do next.

This separation is important when the same person and agent collaborate across several workflows. A role may make the agent generally eligible to perform renewal work, but only the current delegation and resource policy make this particular contract change permissible.

Issue credentials just in time

Long-lived connector tokens are operationally convenient and architecturally dangerous. If copied into a worker, prompt, memory store, or trace, they can outlive the work that justified them.

A credential broker should retain the underlying integration secret and mint or retrieve the narrowest usable credential at execution time.

Diagram 3: shrink authority across time and audience

Each derivation narrows duration, audience, resource, and action until the agent holds only the capability needed for one step.

 Long-lived integration relationship
 ┌──────────────────────────────────────────────────────────────┐
 │ Workspace ↔ CRM connection (stored only in credential broker)│
 └──────────────────────────────────────────────────────────────┘
                         │ derive
                         ▼
 Task delegation
        ┌──────────────────────────────────────┐
        │ W-771: read vendor + draft renewal  │
        └──────────────────────────────────────┘
                         │ derive after policy check
                         ▼
 Step credential
                    ┌───────────────┐
                    │ audience=CRM  │
                    │ record=V-1187 │
                    │ action=READ   │
                    │ TTL=5 minutes │
                    └───────────────┘

 Broad in duration but isolated       Narrow in scope and duration

Where the external system does not support fine-grained tokens, the connector must enforce scope as a trusted proxy. It should validate the platform-issued capability, use the stored integration credential, constrain the request, and record the external identity that the target system will report.

The UI should be honest about that distinction. “Executed by Renewals Agent through the workspace CRM connection” is more accurate than pretending the CRM natively recognized the agent.

Preserve attribution across systems

External tools often record only the integration account. The multiplayer platform therefore needs its own tamper-evident action record:

• requester principal;
• agent principal;
• delegation and work identifiers;
• policy decision and version;
• credential identifier, audience, and expiry;
• normalized action and payload digest;
• external request and result identifiers;
• approval, if required.

Correlation metadata should be sent to the external system whenever it supports custom headers, fields, comments, or actor tags. That creates a bridge between the internal record and the target system’s audit history.

This improves incident response for users. An administrator can start from a suspicious CRM change and trace it back to the exact work thread, agent, delegator, approval, and evidence.

Revocation has to reach active work

Disabling an agent in a settings page is insufficient if existing queues, cached policy decisions, or active credentials continue working.

Revocation should:

1. change the principal or delegation status authoritatively;
2. publish a revocation event;
3. prevent new credentials from being issued;
4. invalidate or blacklist active credentials where possible;
5. cancel or quarantine queued commands;
6. re-evaluate in-flight work before the next external effect.

The product should then show affected work as “paused because this agent’s access was revoked,” not as a generic failure. Users need a recovery path: reassign the work, restore a narrower grant, or cancel it.

Protect against the confused deputy

An agent can become a confused deputy when it has authority that a requester lacks and acts on the requester’s instruction without verifying the delegation.

For example, a procurement agent may be able to read every vendor contract, while an individual requester may only see their region. The agent must not become an alternate search API that bypasses the requester’s boundary.

A safe effective scope is usually the intersection of:

• the agent’s declared role;
• the requester or delegator’s authority;
• the work-specific delegation;
• the target resource’s policy;
• the allowed business purpose;
• the current risk classification and approval state.

The agent receives only the authority common to all applicable boundaries. A broad agent role cannot widen a narrow human delegation, and a powerful requester cannot make an agent exceed its own risk ceiling.

There are exceptions, such as a compliance agent intentionally operating with independent authority. Those should be explicit service mandates, not accidental consequences of broad credentials.

Identity should make the product easier to understand

Security architecture fails when it produces only administrative complexity. First-class agent identity should improve the everyday experience:

• assignment lists can include agents and people consistently;
• activity states name the actual actor;
• approval prompts explain the delegated boundary being crossed;
• revocation affects one agent rather than every connected user;
• audit history reads like a chain of responsibility;
• handoffs preserve ownership without sharing credentials.

The series begins with multiplayer AI as a distributed systems problem, then explains why approval gates are a systems primitive. The broader product requirements are covered in designing a multiplayer AI workspace.

Give agents less authority, more explicitly

The goal is not to make an AI agent look indistinguishable from a colleague. It is to make its delegated authority more precise than the authority usually given to automation.

SoftworkerAI is being built around named agents, scoped access, explicit delegation, approval gates, and a record of every consequential action. If your organization is working through agent identity and connector access, join the early-access program and share the boundary that is hardest to express in your current systems.