Credential forwarding is the act of sending a live authentication token or session credential along with a request to another endpoint. When it happens without clear user consent, the receiving server can act as the user within the scope of that credential. The risk is highest when the destination can be changed through configuration.
Expanded Definition
Credential forwarding occurs when a live session credential, bearer token, or delegated authentication artifact is attached to a request and passed to another endpoint so that the destination can act on the original identity’s authority. In NHI environments, the distinction from ordinary authentication is important: the credential is not merely presented to prove identity once, it is forwarded in a way that extends trust across systems.
Definitions vary across vendors on whether forwarding includes only direct token relay or also proxy-mediated delegation, but the security concern is consistent: the receiving service can inherit more privilege than intended if the token scope is broad or the target is configurable. This is especially relevant when AI agents, workflow automation, or service-to-service calls operate with tool access. The most common misapplication is treating forwarded credentials as harmless transport metadata, which occurs when engineers change the destination endpoint without re-evaluating the token’s audience, scope, and user consent.
For a standards-oriented baseline, compare this pattern with OWASP Non-Human Identity Top 10 and identity assurance guidance in NIST SP 800-63 Digital Identity Guidelines.
Examples and Use Cases
Implementing credential forwarding rigorously often introduces routing and trust-boundary constraints, requiring organisations to weigh service continuity against the cost of tighter token binding and destination validation.
- A workload proxy forwards a bearer token to an internal API so the downstream service can execute actions on behalf of the original caller. This is legitimate only when the audience and scope are tightly constrained.
- An AI agent passes a session credential to a tool endpoint to retrieve files, query tickets, or launch automation. If the tool target is reconfigured, the credential may suddenly authorize a different system.
- A CI/CD job forwards cloud credentials into build steps. If logs, plugins, or child processes inherit those values, the forwarded credential can become a lateral movement path, a pattern often seen in incidents like the CI/CD pipeline exploitation case study.
- A service mesh or reverse proxy relays a user token to a backend microservice. If the backend assumes direct user intent rather than delegated authority, authorization decisions can be overstated.
- In secret-sprawl scenarios, teams may forward tokens through scripts or messaging systems instead of using short-lived exchanges, a practice discussed in the Guide to the Secret Sprawl Challenge.
For implementation patterns that reduce dependency on reusable secrets, see the Ultimate Guide to NHIs — Static vs Dynamic Secrets and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Why It Matters in NHI Security
Credential forwarding matters because it turns one trusted identity into a portable authorization object that may survive beyond the original user or system context. In NHI security, that is dangerous when workloads, bots, and AI agents can change destinations, chain tools, or inherit permissions through configuration. The main failure mode is not just theft of the credential, but unauthorized reuse at a downstream service that was never meant to receive it.
This risk is amplified by weak secret handling and low operational confidence. In the 2024 Non-Human Identity Security Report, 88.5% of organisations said their non-human IAM practices lag behind or are merely on par with human IAM, and 59.8% saw value in dynamic ephemeral credentials. That gap helps explain why credential forwarding so often persists in scripts, proxies, and automation pipelines instead of being replaced by scoped delegation.
Practitioners should treat forwarding as a governance issue, not a convenience feature. It becomes operationally unavoidable after a token is replayed, a tool endpoint is swapped, or an automation path is abused and access has to be traced across systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Forwarded credentials expand secret exposure and misuse risk across NHI trust boundaries. |
| NIST SP 800-63 | AAL2 | Credential forwarding affects how identity assurance is preserved across sessions and delegates. |
| NIST CSF 2.0 | PR.AA-01 | The term maps to access control decisions about how identities are asserted and used downstream. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires explicit verification before a forwarded credential is trusted by another service. |
| CSA MAESTRO | Agentic workflows must govern delegated access when tools forward live credentials. |
Ensure forwarded credentials retain intended assurance and are not accepted outside their authenticated context.
