DeployBot receives a long-lived token to publish artifacts from the build pipeline. A job prints the token into CI logs, an attacker retrieves the log output, and the same token successfully publishes an internal package from a new IP address. The attacker did not need an employee password, a phishing page, or a user session. The attacker only needed a credential that represented an automated principal.
A non-human identity is the principal behind an automated workload, service, pipeline, device, or agent. In this environment, DeployBot has authority because downstream services accept its token, not because a human completes MFA at each request. The defender’s question is therefore operational: how do we issue narrowly scoped authority, rotate it without breaking production, and recognize misuse when the credential escapes its intended runtime?
The simplest failure has one input and one outcome. DeployBot presents a copied bearer token to the artifact registry, and the registry publishes an artifact because the token remains valid and carries the required permission. A token proves possession, not the legitimate location or process that obtained it, unless the surrounding identity design adds those checks.
Boundary rule A non-human credential must identify a principal, limit its authority, and remain observable after issuance.
The token leak matters because DeployBot is only one identity path in prod-gke-1. The Kubernetes cluster runs Orders API, Billing API, and Inventory API. Alongside those services, SupportAgent calls approved support tools, ETLBot imports data, and DeployBot builds and publishes artifacts. Each principal creates an authorization decision, a credential lifecycle, and evidence that defenders must retain.
The attack surface is not the cluster alone. Requests cross the cluster boundary, the service-mesh boundary between workloads, the artifact registry, the secrets store, the identity provider and authorization server, and external SaaS provider APIs. A credential copied from one boundary can be accepted at another when policies treat the credential as sufficient proof without considering its issuer, audience, workload, source, or permitted action. The environment below gives the later controls one consistent target.
Let’s trace where credentials and tokens cross those boundaries:
This diagram shows that authority moves with tokens across several systems, while each system records only part of the request trail.
Because the inventory names every authority path, we can model the failure before choosing a control. A leaked API key from a repository or CI log lets an attacker impersonate the principal until revocation. A stolen OAuth client secret can mint fresh access tokens. A replayed access token may work from an unexpected network or runtime. These are different theft paths, but each crosses the same boundary: an external actor presents credentials intended for a controlled workload.
Overbroad scope changes the impact after theft. If SupportAgent can read billing records and invoke a refund tool under one broad grant, a prompt-driven tool request or compromised agent component can cause an action outside the requester’s intended authority. This is a confused deputy problem: a service with legitimate authority performs an action for an untrusted or insufficiently authorized caller. The control is not merely stronger authentication. The tool call needs an explicit policy that binds the requesting principal, target resource, and allowed operation.
Rotation introduces a quieter failure. A secrets store may contain a replacement credential while ETLBot continues using a cached old secret, or a downstream SaaS provider may still accept both versions longer than planned. Rotation is complete only when the old credential cannot authorize requests and the workload has proved it can use the replacement.
The later build pairs each threat with prevention and evidence:
The comparison below keeps the boundary, prevention measure, and evidence source attached to each credential failure.