Agent Identity: Separate the User, Agent, and Execution Instance

Author: Max Luo · October 11, 2026 · Teloa AI Security

A request containing user_id has not necessarily authenticated that user. A process with an agent name is not necessarily authorized to act under that identity. Enterprise agent identity must answer three different questions: who initiated or delegated the authority, which logical agent is executing, and which running instance holds proof for the invocation.

This article follows an employee initiating a ticket-summary task through IM. It develops channel binding, instance registration, gateway authentication, and disablement flows. JSON fields and procedures are reference designs, not standard protocols or claims that Teloa implements every control. The normative basis is V1 of the baseline; verify levels and applicability against the original requirements.

1. Establish three identities, then bind task and tenant

The platform binds these identities to a task, tenant, workspace, and connector. A request cannot freely recombine them. A valid credential for run-17 does not permit its arguments to rebind it to an administrator or another tenant. An owner's name is a governance attribute, not an authenticated execution principal.

Distinguish acting on behalf of a user from an autonomous agent. A delegated agent is bounded by the user's rights. An autonomous agent, as defined by the baseline, has a separate non-human identity; its owner governs it, but the platform must not borrow that person's account. A highly automated scheduled task may still be a user-delegated task. V1.3.2 and V2.3 assign different identity and authority responsibilities to these modes.

2. A channel binding must prove both sides

A binding must establish ownership of the channel account and the enterprise identity. Completing SSO and then trusting an IM identifier supplied by the browser can still bind an attacker's channel account to a victim's enterprise identity.

One reference procedure is:

1. Validate the channel provider's signature, timestamp, and event deduplication identifier. Obtain its organization and stable account identifiers from the validated event.
2. Create a short-lived, single-use server-side transaction binding those identifiers to the expected enterprise tenant and callback state. Give the browser only a random transaction reference.
3. Authenticate through the enterprise IdP and validate the result against the transaction. An OIDC authorization-code flow must perform its applicable state, nonce, and PKCE checks; an unvalidated token payload cannot establish a binding.
4. Resolve the validated IdP identity in the directory; check user status and tenant consistency. On the authenticated enterprise-user screen, display the server-fixed channel organization and account and require explicit confirmation of the binding intent. Also verify channel-account ownership through the original channel or a provider-verifiable association mechanism. Channel-side confirmation alone lets an attacker forward a binding link, induce a victim to authenticate, and confirm from the attacker's own channel account.
5. Atomically consume the transaction and create the binding. Rebinding, cross-tenant association, and account recovery require renewed verification; removing an old binding is audited.

Map users through a verified issuer and subject. OpenID Connect Core defines issuer-local subjects and pairwise identifiers. Do not assume the same subject across clients or fall back to automatic account merging by email.

{
  "channel_key": ["im-provider", "org-a", "channel-user-81"],
  "enterprise_user": "user-42",
  "verified_idp_identity": {
    "issuer": "https://idp.corp.example",
    "subject": "idp-subject-4281"
  },
  "tenant": "tenant-a",
  "binding_transaction": "bind-902",
  "status": "active"
}

This is a server-maintained record, not an arbitrary client binding request. Display names, nicknames, and email From addresses are presentation attributes. DMARC helps validate the sending domain; it does not independently authenticate an employee or authorize enterprise actions. Email channels must also satisfy V1.2.6's external-domain restriction and the other applicable identity controls.

3. Bind identities when the execution instance starts

Before creating run-17, the control plane verifies user status and the agent configuration, then registers the relationship tenant-a / user-42 / agent-support / task-17 / run-17. Credential possession must be separated from the model, executable code, and ordinary tool returns.

Validated channel event → resolve binding and user status
                        → create task and register run-17
                        → issue audience-restricted workload proof
                        → controlled identity component authenticates
                        → gateway resolves the trusted principal

If JWTs are used, an internal platform proof payload might resemble the following. Private claims illustrate the binding. This is neither an ID Token nor a general OAuth token to forward to third-party SaaS. Its 300-second lifetime is an example, not a universal baseline limit.

{
  "iss": "https://workload-issuer.corp.example",
  "sub": "workload:run-17",
  "aud": "egress-gateway",
  "iat": 1791676800,
  "exp": 1791677100,
  "jti": "proof-017",
  "tenant_id": "tenant-a",
  "task_id": "task-17",
  "registry_revision": 7
}

Signature validation is insufficient. The gateway restricts issuers, algorithms, and key sources; checks audience, lifetime, and the chosen token type; and verifies that the instance remains active and matches the task and registry revision. A kid selects an already trusted key, not an arbitrary verification URL supplied by the caller. Current permissions and account status come from the control plane rather than a permanent copy from issuance time.

A deployment using the OAuth JWT access-token profile must follow RFC 9068's resource-server validation rules, rather than disguising this private proof as a standard access token. JWT signatures provide integrity, not payload confidentiality. Base64-decoded claims are not verified identity.

4. Recover the principal at the gateway; examine proxy boundaries

V1.4.3 requires the gateway to derive the user and agent solely from workload identity. Authenticate the workload, resolve trusted registration, check status, then supply the recovered principal to the policy service. Arguments named user_id or agent_id may be business inputs requiring validation; they must not override authentication.

A common proxy bypass occurs when a reverse proxy sets X-User-ID, but the gateway also accepts direct clients and trusts the same header. Remediation requires network restrictions, trusted-proxy authentication, and removal or replacement of client-supplied identity headers. Changing header precedence alone does not close the path.

A sidecar can separate keys from model context, but does not automatically establish a security boundary. If arbitrary sandbox processes can use its signing interface, a compromised process can still submit requests under the instance's identity. Restrict control interfaces and file access, prevent cross-instance borrowing, and continue resource-level authorization on every invocation. An authenticated workload may still be malicious.

Workload authentication establishes who is calling. It does not establish that the proposed operation is safe. That distinction is the boundary between this article and the authorization article.

5. Distinguish workload attestation from software integrity

V1.4.5 places pre-issuance workload attestation at L3. SPIRE's concepts distinguish node attestation from workload attestation, which checks process properties against registered selectors. These provide an identity-issuance basis.

Instance granularity still needs design. If every container shares a service-level SPIFFE ID, the gateway identifies a service, not a particular session. Maintain instance-specific registration, or use a controlled broker to bind execution context to an attested service identity. The control plane must generate that association.

Attestation does not prove that code has never been compromised. Image signatures, dependency pinning, and runtime isolation address supply-chain and execution risks separately. A valid certificate cannot replace them. L1 and L2 deployments still need their applicable short-lived instance identity controls, but this article does not make installing SPIRE mandatory for those levels.

6. Downstream tokens distinguish subject from actor

The gateway translates internal workload identity into an authorization form accepted downstream. RFC 8693 defines act for the current actor alongside the subject. The following only illustrates that relationship; a trusted authorization server issues the actual token with its required scope, lifetime, and audience.

{
  "sub": "user-42",
  "aud": "tickets-api",
  "scope": "tickets:read",
  "act": { "sub": "agent-support" }
}

Nested actors are history, not additive grants. RFC 8693 excludes prior actors from resource-server access-control decisions. Enforce narrowing in trusted authorization and policy services, convey the resulting current authorization, and retain the chain for audit. Finding an administrator in the history must not authorize access.

Token exchange does not automatically prevent privilege escalation. The authorization server still decides who may represent whom, for which resources, and under which active delegation. An autonomous agent uses its own non-human principal and must not impersonate an employee in downstream logs.

7. Short-lived identity still needs active revocation

Expiry only establishes an upper time bound. If a gateway checks only a token with five minutes remaining after the user is disabled, access can continue. Rotating certificates may also leave an existing TLS connection usable.

A reproducible revocation flow updates user status, invalidates bindings, stops tasks and instances, prevents new issuance and renewal, blocks gateway credential retrieval and invocation, revokes applicable refresh tokens and connections, and terminates running tasks and retries. Close existing connections where required, or check instance state on each request. Register downstream revocation capabilities separately.

CREATED → ACTIVE → STOPPING → REVOKED → DESTROYED
             │
             └─ expiry / user disabled / agent disabled / session ended

State transitions must prevent renewal after disablement and revival of stopped tasks through retries. Bound status-cache lifetimes, reconcile missed events, and reject high-risk calls when current status cannot be established. V1.4.4 requires immediate identity revocation on session termination or instance destruction. V10.4.1 requires denied calls within an agreed window after user disablement or permission reduction. Neither control can be reduced to waiting for JWT expiry.

Probe gateways and connectors continuously from before disablement. Record the disablement event, last successful call, and first subsequent continuously denied interval. The last success is only a lower bound; sparse probes can underestimate delay. Report the observed interval, sampling period, and cache configuration, and check the agreed upper limit through sustained denial without later successes. No observed post-disablement success does not establish zero latency. Revocation does not roll back effects already submitted downstream; track and handle them separately.

8. Validate the identity chain with eight experiments

Retain authentication events, binding revisions, registration, denial reasons, disablement timestamps, and downstream logs. Do not store raw tokens or private keys. Token identifiers, certificate fingerprints, and restricted principal references support correlation. A stolen JWT bearer credential may be replayable: a claim that instance binding prevents this attack needs evidence of possession binding, protected keys, or an equivalent mechanism, not just an instance name in the payload.

After verifying identity, still ask whether this principal may perform this operation on this resource. Continue with authorization and execution, or revisit threat modeling and assessment. Teloa AI Security maintains the baseline and assessment tool, derived from Teloa development practice.