Non-Human Identity for AI Agents: Secure Every Avatar Service

Non-human identity for AI agents should begin with one rule: every independently authorised avatar service gets its own verifiable workload identity. The speech recogniser, retrieval service, policy gateway, rendering worker and business-system connector should not all inherit one shared service account simply because they belong to the same application.

For banks, governments and regulated enterprises, this creates a clean answer to a basic security question: which running component requested this data or action, in which environment, for which session, under whose delegated authority? Network location, a container name and possession of a reusable API key are weak substitutes.

This guide maps eight identity subjects, a five-step trust path and twelve production tests for private real-time avatar systems. It complements Yepic’s guide to secure avatar SSO: SSO identifies the human user; workload identity identifies the software acting after that user signs in.

Do not confuse the avatar’s face with its security identity

An avatar may have a recognisable face, voice and persona. Those are presentation assets and behavioural configuration, not authentication evidence. The security subject is the workload that is asking another service to trust it.

Keep four concepts separate:

• Human identity identifies the customer, employee, operator or administrator.
• Workload identity identifies a running service, job or device such as the production retrieval service.
• Credential is the certificate, token or secret used to prove an identity.
• Delegated authority states what a workload may do for a particular user, tenant, purpose and period.

A credential is not the identity itself. The Cloud Security Alliance’s July 2026 definition of non-human identity makes the same distinction between the identity subject and its authentication mechanism. This matters operationally: rotating a certificate should not create a new service identity, while moving a stolen static key to another host must not make that host trustworthy.

Map eight non-human identities in the avatar path

A real-time avatar is a system of systems. Treating the entire chain as one principal creates authority that is too broad and evidence that is too vague.

1. Session gateway

The gateway accepts a verified user session, creates the avatar session envelope and passes only the minimum claims downstream. Its identity should not grant direct access to every knowledge source or business action.

2. Speech and language services

Speech recognition, translation and language detection may process live audio or text. Give each service access only to the approved media path and model resources for its role. A speech worker does not need permission to retrieve account records.

3. Knowledge retrieval

The retrieval service needs a distinct identity because it crosses into document repositories, databases and vector indexes. It should enforce the user’s permitted scope before returning passages. Yepic’s AI agent secrets-management architecture explains why the database credential must remain outside model context even when retrieval is initiated by a model.

4. Reasoning and orchestration

The orchestrator selects models, proposes tools and manages turn state. Its identity may call approved internal interfaces, but it should not inherit a master credential for the systems those interfaces protect. A generated tool request is input to an authorisation decision, not evidence of authority.

5. Policy and action gateway

This service validates the proposed operation, delegated user context, tenant, data class and approval state. It exchanges verified identity for narrowly scoped downstream authority. Separate read, prepare and execute paths where the business consequence warrants it.

6. Voice, avatar and media workers

Text-to-speech, avatar rendering and WebRTC services need model, asset and media permissions. They normally do not need the customer’s business-system privileges. A compromised renderer should not become a route to a payment API or citizen record.

7. Telemetry and support services

Monitoring agents, log shippers and support collectors are identities too. Give them structured health and diagnostic access, not automatic access to prompts, audio or retrieved content. Their permissions should follow the same data-classification rules as the services they observe.

8. Deployment and update systems

CI/CD runners, model registries and configuration controllers can change the production system. Their identities are administrative and should remain separate from runtime identities, with stronger approval, provenance and revocation controls.

Build a five-step trust path

The architecture should establish trust at runtime rather than assume that anything inside a private network is legitimate.

1. Attest the workload. Bind identity issuance to evidence such as the approved service account, namespace, node, binary or container digest, device state and environment. Select evidence the platform can verify; a self-declared process name proves little.
2. Issue short-lived proof. Provide a temporary certificate or token to the verified workload. Avoid distributing reusable secrets where the destination protocol supports federation or brokered access.
3. Authenticate both ends. The caller verifies the destination and the destination verifies the caller. Mutual TLS, signed tokens and workload-identity federation are implementation patterns, not universal requirements.
4. Authorise the specific call. Evaluate caller identity, destination, operation, environment, tenant, session and delegated user context. Authentication answers “who”; policy still decides “may it do this now?”
5. Record the decision. Preserve identity, policy version, requested scope, result, expiry and correlation reference without copying the credential or unnecessary customer content into logs.

NIST SP 800-207A describes identity-tier policies for cloud-native applications across multiple locations and explicitly removes implicit trust based only on location or ownership. Its zero-trust model for cloud-native access is relevant to on-premise and hybrid designs, but it does not mandate a particular service mesh or identity product.

Use identity-first access, not a larger secrets vault

A secrets vault is useful when a legacy dependency still requires a password or API key. It does not solve identity by itself. If every replica can retrieve the same long-lived secret, the destination still cannot distinguish the production retrieval service from an unauthorised copy.

Prefer a progression:

1. Remove credentials the service does not need.
2. Replace shared credentials with a distinct identity per workload and environment.
3. Use attestation and federation so the workload can obtain short-lived proof without storing a bootstrap secret.
4. Exchange that proof for an audience-, action-, tenant- and time-bounded token where a downstream system requires it.
5. Keep unavoidable reusable secrets behind a broker that verifies workload identity and applies policy before release.

SPIFFE’s workload-identity model is one open example: a workload proves a SPIFFE ID with a verifiable identity document. Kubernetes similarly gives processes a ServiceAccount identity. Neither is automatically secure, sufficient or required for Yepic. Default service accounts, broad role bindings and weak registration can reproduce the same shared-identity problem under newer names.

Keep user delegation and workload authority separate

One service call may involve two valid subjects: the retrieval service and the signed-in employee for whom it is acting. Do not collapse them into a single opaque token.

The protected system should be able to determine:

• which workload made the request;
• which user or service initiated the session, if relevant;
• which tenant and purpose apply;
• which operation and data scope were delegated;
• which policy issued that authority; and
• when the authority expires or can be revoked.

Delegation must never let the workload amplify the user’s rights, or let an overprivileged user bypass controls imposed on the workload. The effective permission should be the constrained intersection of user authority, workload authority, policy and transaction state.

Create a non-human identity register

For every workload identity, record the owner, purpose, issuing authority, attestation basis, environments, allowed audiences, operations, data classes, tenants, credential lifetime, rotation method, revocation path, dependencies, monitoring and retirement trigger.

Link the register to the deployment inventory rather than maintaining an isolated spreadsheet. New service replicas should inherit an approved identity pattern, not create unmanaged accounts. A change in model or container version should not silently widen permissions.

The OWASP Non-Human Identities Top 10 highlights improper offboarding, secret leakage, insecure authentication, overprivilege, long-lived secrets, environment isolation and identity reuse. Treat it as a threat checklist, not proof that a deployment is compliant.

Choose the control plane by deployment model

Customer-hosted deployment can integrate workload identity with the customer’s PKI, identity provider, secrets platform, Kubernetes estate and network policy. It also makes the customer responsible for trust roots, registration, time synchronisation, certificate renewal, disaster recovery and offboarding. Running on the customer’s GPUs does not create identity automatically.

Private or sovereign cloud can use managed workload-identity services while keeping data and evidence in an approved tenant or jurisdiction. Buyers should test what the cloud operator, platform team and application supplier can each impersonate or administer.

Managed public cloud can simplify short-lived credentials, federation and rotation. It may also constrain the identity evidence, token claims and audit detail exposed to the customer. The responsibility split belongs in the architecture and contract, not in assumptions attached to the word “managed”.

Restricted or disconnected environments may need local trust anchors, offline issuance and explicit renewal windows. Long credential lifetimes make disconnection easier but increase replay and revocation risk. The appropriate design requires custom engineering around availability, clock integrity and recovery.

Run twelve production tests

1. Start an unregistered copy of a service and confirm it receives no identity.
2. Move a credential to another host, namespace or environment and confirm replay fails.
3. Use a development identity against production and confirm denial.
4. Ask the speech worker to query protected knowledge and confirm it lacks authority.
5. Request a token for the wrong audience, tenant or operation and confirm denial.
6. Remove delegated user context and confirm personalised access stops.
7. Try to use a valid user session through an unapproved workload and confirm denial.
8. Rotate identity proof during active sessions and verify the defined continuity behaviour.
9. Revoke one workload and measure when new calls cease.
10. Disable the issuer and verify a bounded reduced-service or human-handover state.
11. Retire a component and prove its accounts, role bindings, credentials and trust entries are removed.
12. Trace one business action from human session through every workload identity and policy decision to the downstream receipt.

Make identity part of the integration design

Yepic’s Abu Dhabi Aviation and Oracle enterprise avatar integration joined real-time streaming, enterprise data, API and iframe integration, captions, microphone behaviour, WebRTC testing, browser remediation and cybersecurity support across development and production environments. That project demonstrates why an enterprise avatar spans more security subjects than the face visible to the user.

It is not presented as a completed customer-hosted non-human-identity deployment. Yepic can scope cloud, private-cloud, sovereign and customer-hosted avatar systems—including deployments on customer-controlled GPUs where appropriate—but the identity pattern must fit the selected speech, knowledge, model, media and enterprise components.

Before procurement closes, ask the supplier and internal platform team to draw every service-to-service call. Name the caller, proof, audience, delegated user, policy, credential lifetime and revocation test for each arrow. Any line labelled merely “internal”, “trusted network” or “uses API key” is an unresolved design decision.