An AI application typically involves several distinct services calling each other: a frontend calling an application backend, the backend calling a model provider, the model's decision triggering a call to a tool service, the tool service querying a data store. At every one of these hops, service-to-service authentication needs to correctly propagate the original requesting user's identity, not collapse into a single, broad service credential that loses track of who the request is actually acting on behalf of.
Why identity propagation matters more here than in many conventional systems
The least privilege discussion running throughout this content series depends entirely on every layer being able to check the actual requesting user's permissions, not a generic service identity's broader permissions. If identity gets lost or flattened at any hop in the chain, from the backend to the model provider call, from a tool call to the underlying data query, every downstream authorization check depending on knowing who the request is really for becomes ineffective, no matter how carefully that check's logic gets written.
Use a token or claim that carries the original identity through every hop
Design the service-to-service authentication mechanism, whether a signed token, a claim embedded in a service mesh context, or an equivalent pattern, to carry the original requesting user's identity and relevant permissions through every hop in the chain, rather than each service authenticating to the next using only its own service-level credential with no reference to the original user. This is the technical mechanism that makes downstream authorization checks, covered throughout tool authorization guidance, actually meaningful rather than checking a generic service identity's broad access.
Verify propagated identity at each hop, not only at the entry point
Each service in the chain should independently verify the propagated identity claim is valid and hasn't been tampered with, rather than trusting that whatever identity information arrives from the previous hop is automatically correct. This distributed verification, rather than trusting the chain implicitly after an initial entry-point check, follows the zero-trust principle already well established in conventional microservice security, extended explicitly to cover the AI-specific hops in this architecture.
Distinguish user identity from service identity clearly in logs and checks
Design logging and authorization checks to clearly distinguish which identity is relevant for a given decision: the service making the technical call versus the user the call is ultimately acting on behalf of. A tool's authorization check should generally evaluate the user's permissions, not the calling service's own permissions, which are typically broader and meant only to authenticate that the call is coming from a legitimate internal service, not to authorize the specific action on the user's behalf.
Handle service-initiated actions without an originating user explicitly
Some AI system activity, a scheduled task, an automated background process, might have no originating user identity to propagate at all. Design explicit, distinct handling for this case, using a specific service identity with its own scoped, deliberately limited permissions, rather than defaulting to a broad administrative identity just because no specific user identity was available to propagate, covered in least privilege guidance elsewhere.
Rotate and scope service credentials the same as any privileged credential
Service credentials used for the technical authentication between hops, distinct from the propagated user identity, deserve the same secrets management discipline covered in earlier guidance: scoped narrowly to what each specific service actually needs to call, and rotated on a defined schedule.
Test identity propagation directly across the full chain
Test that a request's original identity actually propagates correctly through every hop by tracing a specific test request end to end and confirming the identity used for authorization at the final hop matches the original requester, following the integration testing discussion in earlier guidance, rather than assuming propagation works correctly based on a design review alone.
Where TELEON fits
TELEON's policy enforcement, applied through the gateway or supported middleware, evaluates authorization based on the identity presented to it at the point of a tool call, which depends on the calling application correctly propagating the original user identity through to that point for the evaluation to be meaningful.
Designing the specific service-to-service authentication mechanism and verifying identity propagation across every hop in a given architecture remains application and infrastructure engineering work specific to each organization's own service topology.
A short checklist
- Carry the original requesting identity through every service hop, not
only a service-level credential.
- Verify propagated identity independently at each hop, not only at the
entry point.
- Distinguish user identity from service identity clearly in logs and
authorization checks.
- Handle service-initiated actions without an originating user through
explicit, scoped service identities.
- Rotate and scope service credentials with the same discipline as any
privileged credential.
- Test identity propagation directly across the full request chain.
Service-to-service authentication in an AI architecture only supports meaningful, least-privilege authorization if the original requesting user's identity actually propagates correctly through every hop, since a downstream authorization check evaluating a generic service identity instead of the real requester provides considerably weaker protection than its presence in the architecture might suggest.