The scenario
A platform team builds a staging environment with its own deploy identity, deploy-staging, and gives it permission to create and destroy infrastructure freely, because staging is meant to be disposable. When production is stood up months later the deadline is tight and the pipeline already works, so the same identity and the same credential are wired into the production pipeline behind a new environment variable. The plan is to split them once the launch settles.
Two years on, deploy-staging is referenced by forty-one pipelines, a developer's laptop, two scheduled jobs and a notebook used for demos. It can destroy production infrastructure, and it authenticates from staging runners that any developer can modify. A junior engineer testing a cleanup script in staging once came within a confirmation prompt of deleting a production cluster. Because the identity's name says staging, every reviewer who has seen it in a production log has assumed it was a harmless artefact.
Why it happens
- Environments are separated by convention, not by identity. Names, tags and variables distinguish staging from production; the credential that acts in both does not.
- Reuse is the fastest path. Copying a working identity into a new pipeline avoids a permissions negotiation, and nothing notices the same credential authenticating from two environments.
- Lower environments have weaker controls by design. Anyone who can change a staging runner can use whatever identity that runner holds, including one with production authority.
- Two OWASP categories fail together. In the OWASP Non-Human Identities Top 10, NHI8, environment isolation, breaks because of NHI9, NHI reuse: the boundary is only as strong as the most-shared identity crossing it.
How Trustivan helps
Classify every identity by environment. Discovery records the account or cluster each identity lives in, and an environment can be marked production, which weights the findings raised against it.
AvailableDetect reuse from authentication, not from names. The same credential seen authenticating from staging and production is a reuse finding regardless of its name. No connector collects authentication events yet, so this is a future capability.
Future capabilityEvaluate cross-environment reach. Effective access and transitive reach show which production resources a staging identity can reach, as an upper bound. A dedicated environment-boundary policy does not exist yet.
AvailableSplit with a plan, not a guess. The identity graph lists the workloads and roles connected to deploy-staging that the connectors can see, so a production-only identity can be introduced with its dependencies known. Pipeline variables are not read.
AvailableKeep the boundary after the project ends. Environment-boundary findings that re-open when a new identity crosses over are a future capability; until then the graph shows the reach whenever it is asked.
Future capability
What the evidence looks like
The fix has to name every consumer of the shared identity, because it is a migration, not a deletion. Illustrating the problem, for the staging deploy identity:
| Question | Illustrative answer |
|---|---|
| Why | One deploy identity authenticates from staging and production and can destroy production infrastructure |
| What | deploy-staging · automation identity · one shared long-lived credential |
| Who | Owner: platform team; consumed by 41 pipelines, 2 scheduled jobs, 1 notebook and 1 laptop |
| Where | Staging runners (developer-modifiable), production deploy pipeline, analyst notebook |
| How | Cloud credential stored as a CI variable in both environments; no federation, no expiry |
| Blast radius | Production cluster, 3 databases, the DNS zone, the infrastructure state bucket |
| Recommendation | Issue deploy-prod with federated short-lived credentials; migrate the 41 consumers; restrict deploy-staging to the staging account |
| Action | Consumer list exported · migration sequence drafted · staging-only policy staged for review |
| Evidence | Authentication logs from both environments · CI variable inventory · infrastructure state references · identity creation record |
Related capabilities
- Access Intelligence — effective access and transitive reach across environments
- DevOps & CI/CD — GitHub App installations and bot accounts; runners and workflow identities are not read
- NHI Governance — environment policy as tracked findings with owners
- Discovery & Inventory — the account or cluster each identity lives in, with evidence
- Posture Management — boundary violations and drift kept visible after the fix