The Identity Layer: Agents Need Two Identities, Not One

Agent identity bugs are rarely dramatic at first. They look like small mismatches.

The agent updates the wrong account because the CRM customer and billing customer share an email address. It files a case note as the service account instead of the delegated operator. It remembers a preference from one tenant and recalls it in another. It calls a tool with broad platform credentials because nobody modeled the difference between “the user asked” and “the agent is allowed.”

These are not prompt problems. They are identity-layer problems.

The Identity Layer is the Intelligence-plane contract that tells the rest of ContextOS what an entity is, who the human actor is, which workload is acting, and which credentials may be exchanged at each boundary.

Entity identity: what the run is about

Most enterprise data has many identifiers for the same thing. A customer has a CRM id, billing id, support id, marketing id, and maybe several email addresses. A dataset has a catalog id, storage path, warehouse table, and owner label. A policy has a document slug, version id, effective date, and exception list.

ContextOS uses canonical entity IDs, or CEIDs, to keep those references stable across runs:

{
  "subject_ids": [
    {
      "type": "customer",
      "ceid": "ceid_customer_8f4a",
      "source_refs": [
        "crm:contact_881",
        "billing:acct_4409"
      ]
    },
    {
      "type": "order",
      "ceid": "ceid_order_19ac",
      "source_refs": [
        "orders:ord_991"
      ]
    }
  ]
}

The agent does not get to decide that two records are the same because the names look similar. Entity resolution is a governed service with confidence, provenance, collision handling, and human review for risky merges.

Actor identity: who delegated authority

A human user may ask for a task, but that does not mean every downstream action is authorized. The RunContext should carry the delegated actor explicitly:

{
  "user": {
    "user_id": "usr_204",
    "tenant_id": "tenant_acme_prod",
    "roles": ["support_manager"],
    "delegation": {
      "mode": "on_behalf_of",
      "expires_at": "2026-05-14T18:00:00Z",
      "allowed_intents": ["support.refund.review", "support.refund.execute"]
    }
  }
}

This tells the Policy Engine which human authority is in play. It does not automatically authorize an action. A destructive refund still needs the required evidence, approval mode, and gateway check.

Workload identity: which agent is acting

The agent also needs its own identity. That identity should answer:

which agent definition is running,
which version produced the plan,
which runtime or deployment executed it,
which service account or workload identity is eligible for token exchange,
which owner is accountable for the workload.

{
  "agent": {
    "agent_id": "support_refund_agent",
    "agent_version": "2026.05.14",
    "runtime": "contextos-orchestrator",
    "owner_role": "support_platform",
    "workload_identity": "wi_support_refund_agent_prod"
  }
}

Without workload identity, every incident collapses into “the agent did it.” That is not enough for access review, rollback, or audit.

Credential exchange belongs at the tool boundary

The agent should not hold broad credentials. The Tool Gateway should exchange typed identity claims for a least-privilege credential scoped to the current tool call.

This is the difference between “the agent has access to payments” and “this run, on behalf of this user, under this policy decision, may call payments.issue_refund for this transaction and amount.”

The identity checks that catch real failures

Failure	Identity-layer control
Wrong customer updated	CEID collision checks and source-ref proof.
Cross-tenant memory recall	memory records bound to tenant, subject, consent, and classification.
Agent overuses user authority	delegation scope and expiry checked at every gateway call.
Service account becomes universal key	workload identity mapped to narrow capability scopes.
Audit cannot name the actor	DecisionRecord stores user delegation, workload identity, approver, and trace.
Semantic drift in metrics	SIDs version business definitions separately from raw table names.

Identity is not a login screen. It is a join discipline across the whole runtime.

Memory depends on identity

Promotion-aware memory is only safe when every memory candidate answers four questions:

Question	Example
Who or what is this about?	`ceid_customer_8f4a`, `ceid_dataset_revenue_daily`.
Who observed or approved it?	delegated user, reviewer, system source.
Where may it be recalled?	tenant, domain, data class, consent scope.
When does it expire or require review?	TTL, contradiction status, policy version.

A memory record without identity is just a sticky note with production privileges. It may be useful, but it should not enter compiled context.

Product implication: identity is a user experience

Identity controls should surface in product moments. An approval request should show which user delegated authority, which agent is acting, which subject IDs are affected, and which credential scope will be minted. A trace review screen should group incidents by agent version and workload identity. A memory review queue should show the CEID and the consent scope before promotion.

This is not bureaucracy. It is how the operator develops trust in a system that can act.

Readiness checklist

Every RunContext carries tenant_id, delegated user identity, agent workload identity, and trace id.
Every material business entity has a CEID, source refs, confidence, and collision policy.
Every ML-facing or semantic feature has a versioned SID or equivalent semantic identifier.
Tool calls exchange credentials at execution time through the Gateway.
Memory candidates carry subject identity, source, consent, classification, TTL, and contradiction state.
DecisionRecords store actor, agent, subject ids, approvals, and policy decisions.

Research base

ContextOS spec: Identity Layer, Governance, Memory Model, and API Contracts.
W3C Trace Context for portable trace identity across services.
OWASP Top 10 for LLM Applications for the risk categories that make excessive agency, data exposure, and tool misuse identity problems as much as model problems.