By Luffy Bao, CTO at Ankayma · 4 July 2026 · ← All writing
Almost every pipeline, given enough time, accumulates the same thing: a long-lived deploy secret — an SSH key, a cloud key, a kubeconfig — sitting somewhere in CI so the deploy step can reach production. It's convenient. It's also what leaks. 2025 saw 28.65 million secrets hardcoded into public GitHub commits, the largest single-year jump ever measured; AI service credentials alone rose 81%. This isn't the bad luck of a few careless teams; it's a property of how CI/CD is built today.
When that makes people uncomfortable, the pressure is always to guard the secret better — put it in a vault, rotate it, turn on leak scanning. Those are good, but they don't touch the root: the secret still exists, still long-lived, still has to be present at deploy time. A well-guarded secret is still a secret that can be taken. And one thing makes this root heavier: AI writing code. AI-assisted commits leak secrets at roughly double the human-only rate, because whatever an agent reads in context is, to it, just another string — it has no built-in notion of "this is a credential, don't emit it."
"Access" has two shapes, and they're opposites in the threat model. One is a standing credential: a stored secret, long-lived, waiting to be used. The other is an ephemeral identity: nothing is stored between runs — each deploy proves who it is, receives a scoped, time-limited grant, and that grant dissolves. On a feature list they sound the same ("the pipeline can deploy"). In the threat model, one is a thing that can be stolen, the other leaves nothing to steal between runs.
The honest fix is to remove the long-lived secret, not guard it harder. The direction the industry is moving — and the one I'm building — is per-run identity: the pipeline issues a short-lived token for that run (GitHub Actions and GitLab both emit these on an open standard), which is exchanged for access that lives minutes, scoped to exactly what's needed, reaching exactly the target needed — and expires when the deploy is done. No secret is left sitting in CI to leak. The other half matters just as much: the access itself is recorded — who or what, reaching where, when — into a log that can't be edited. Removing the secret answers "who can get in"; the log answers "who did get in, and what did they do."
When AI runs the deploy, change the question. The tempting question is "how do I make sure the agent never gets fooled?" The blunt answer: you can't guarantee that. Prompt injection is real, and an autonomous agent doing something irreversible — deleting data, pushing to production — won't hesitate or ask. So the right question isn't whether it gets fooled, but: what can a fooled deploy reach, and can you afterward prove exactly what it did? If the agent's identity is short-lived, scoped, time-limited, and every action it takes lands in an immutable log, then a compromised agent can only touch what policy allows, for minutes, and you hold the full record. To be plain: this does not stop the agent from being fooled — it bounds what a fooled agent can reach, and keeps the evidence. Those are two different things, and conflating them is where a lot of "safe AI" promises quietly fail.
Don't skip the cost — this model isn't free, it's different. Ephemeral identity reshapes risk, it doesn't erase it:
Let me state my bias. I'm building a network layer where access is identity-bound, short-lived, and every access lands in an immutable log — at Ankayma — so be skeptical of how I weigh the trade-off. The claim is narrow: the secret-in-CI problem is structural, so the right fix is to remove the long-lived secret, not guard it harder; and for AI in the pipeline, design to bound and record, don't bet on it never being fooled.
So what should you actually ask? Run the question forward. If my CI is compromised tomorrow — or my deploy agent is talked into something it shouldn't do — what can it reach in production, and can I reconstruct exactly what it did? If the answer depends on the scope of a secret sitting somewhere, you have a standing-credential problem — and it's worth fixing at the root.
I write about this because the "secret in CI" conversation is where a lot of pipelines that feel safe are standing on a key waiting to leak, and it's a core part of what I'm building at Ankayma. If you're weighing how a pipeline — or an autonomous deploy agent — can reach production without leaving a long-lived secret behind, I'd like to hear your constraints, including the ones that make my approach look wrong.
Figures on secret leakage (28.65 million secrets, +81% AI service credentials, AI-assisted commits leaking at roughly double the human-only rate) are from GitGuardian's State of Secrets Sprawl 2026 report.
Luffy Bao is CTO at Ankayma, building zero-trust mesh infrastructure for regulated organizations in Southeast Asia and the Gulf. Questions or counterarguments? hello@ankayma.com