DEV Community: Paulo Victor Leite Lima Gomes

Staged npm publishing is production change control

Paulo Victor Leite Lima Gomes — Sat, 24 Oct 2026 09:00:49 +0000

I think we have been lying to ourselves about npm publish.

We call it a release step, which makes it sound small and administrative: tests pass, CI uploads a tarball, someone updates a changelog, and we move on. But publishing a library is closer to a production deployment than it is to uploading a build artifact. The audience just happens to be every application, every developer laptop, and every downstream CI pipeline that trusts that package name.

That is a pretty impressive blast radius for a job step that is often protected by one long-lived secret named something like NPM_TOKEN.

The good news is that npm's publishing model has finally caught up with that reality. Trusted publishing, staged releases, malware scanning, and independent workflow identities let us build a release lane with actual controls. The important part is not ticking a supply-chain-security box. It is deciding that making a package public is a production change and operating it that way.

A registry publish is a deployment with strangers on the other side

When I deploy a service, my team normally has some guardrails: an environment, a deployment record, observable health signals, a rollback plan, and a person who can decide whether to continue. A library publish often has less ceremony despite affecting systems we do not own and cannot observe.

Once a new version is tagged latest, consumers may pull it into fresh CI runs within minutes. A compromised publish workflow can ship credential theft. A packaging mistake can break installs across a wide ecosystem. A post-install surprise can land in a build environment before the consumer has had a chance to understand what changed.

This is not a reason to turn every patch release into a meeting. It is a reason to put the decision at the correct boundary. Producing a package and making it available to the public are different actions. They should not share the same authorization by default.

The release is now a state machine

The useful mental model is:

build → stage → scan → approve → public

That sequence is a meaningful improvement over “CI has a secret, therefore CI may publish.”

In the current npm model, a trusted publisher authenticates with an OpenID Connect (OIDC) identity from its CI provider rather than presenting a reusable registry token. npm checks that identity against a configured repository, workflow, and environment. It also creates provenance automatically for supported trusted-publishing flows. npm's trusted-publishing documentation is worth reading closely because the details are the policy: the identity is not merely “GitHub Actions,” but a particular workflow running in a particular context.

Then comes the part I like most: staging keeps the version out of the public registry until a human approves it. npm scans published packages before they are available for install; a scan can allow, hold, or block a package. Staged packages cannot be approved until that scan is complete. That means the registry itself now acknowledges that availability is a lifecycle, not an instantaneous side effect of a successful command. GitHub's npm update describes the staged history maintainers can review, while the earlier malware-scanning announcement spells out the possible delay and review outcomes.

This is not bureaucracy for its own sake. It buys time for the two questions that matter:

Did the intended release workflow create this exact artifact?
Should this exact artifact become public now?

Those questions are related, but they are not the same question.

OIDC proposes; approval promotes

OIDC is excellent at constraining who may propose a release. A trusted-publishing configuration can say, in effect, “only this workflow in this repository, under this environment, may obtain publish authority.” It removes a copied secret from the pipeline and makes an unexpected publishing attempt easier to reason about.

OIDC does not decide whether the release is sensible. It cannot notice that someone selected the wrong latest tag, that a generated file is missing, or that a perfectly legitimate change needs a careful rollout. It also cannot make a human owner accountable for the public-release decision.

Staging covers that second boundary: who may make it public. It is the change-control gate.

That distinction keeps the design honest. Provenance can establish where an artifact came from; it does not prove that the code is safe or that the release is appropriate. The OpenSSF attestation UX guide makes the same caution in broader terms: attestation is evidence, not a safety verdict. Treat it as useful forensic material and a release-review input, not a green shield beside a dependency name.

An operating model that does not depend on heroic maintainers

The September npm update made multiple trusted-publishing configurations available for a package. That is more than a convenience feature. It lets a team stop pretending all release paths are equivalent.

I would set up three lanes.

Stable releases

Use a dedicated release workflow, ideally protected by the repository's normal review and release-environment rules. It stages a version and produces a release record with the commit, version, changelog, test result, package contents, and provenance link.

Promotion to public should require a named package maintainer with 2FA. For a team, make it a deliberate approval responsibility rather than an ambient permission held by anyone who happens to be on call. The approver checks the staged package, confirms the dist-tag, and records the decision in the normal release trail.

That is not a four-eyes ritual for every typo. For small teams, one accountable maintainer may be entirely appropriate. The control is that the same compromised CI context cannot silently decide to publish broadly.

Prereleases

Use a separate trusted-publishing configuration and workflow for versions such as 2.4.0-rc.1 and tags such as next or beta. Keep its OIDC conditions distinct from the stable-release workflow.

This makes experimentation cheaper without weakening the stable lane. A prerelease can still be staged and scanned, while its distribution tag makes the intended audience explicit. More importantly, a release engineer does not have to retain a broad token simply because the prerelease workflow has slightly different triggers.

Emergency releases

An emergency path should be faster, not invisible. Use another narrowly scoped workflow identity, require a short incident note, and preserve the same staging and human-promotion boundary. A designated incident commander or package owner can approve it, but the exception must leave evidence.

Do not confuse “we need to fix this now” with “we should bypass every control.” The fastest reliable emergency process is the one people have rehearsed: publish a patched version, verify its provenance, move consumers to it, and deprecate a bad version if that is the appropriate registry response. A package version is hard to take back once consumers have cached or mirrored it, which is exactly why the release record matters.

Make the approval observable

There is a failure mode here too: teams add a human button and call it governance, while the button says nothing useful. Then the process becomes an unreviewed rubber stamp with extra latency.

An approver should be able to answer a short set of concrete questions without spelunking through CI logs:

What commit and source repository produced this package?
Which release workflow and environment requested the stage?
What changed from the previous public version?
Did the expected tests and package-content checks pass?
Has registry scanning completed, and what is the state?
Which tag will consumers receive?

Put that information in the release description or a small generated summary next to the approval action. If the answer depends on a maintainer remembering which run URL was the good one, the process is not yet operational.

Keep the evidence after promotion too. GitHub documents how to verify artifact attestations offline, which is useful when investigating a suspicious release or preserving evidence outside a web UI. You do not need to perform offline verification on every ordinary release; you do need a tested procedure for doing it when trust is in question. See GitHub's offline-attestation verification guide.

A Monday-morning migration list

If your current process is npm publish from CI with a long-lived token, I would do this in order:

Inventory publishing authority. Find every publish token, every workflow that can use one, and every person or service account that can change package settings.
Install trusted publishing. Bind separate OIDC configurations to stable, prerelease, and emergency workflows. Keep their repository, workflow, and environment criteria narrow.
Stage by default. npm supports staging by default per trusted-publishing configuration; make direct publishing an exceptional, explicit choice rather than the convenient default.
Name the approvers. Decide who may promote stable versions, who covers incidents, and what evidence they must review. “Any maintainer” is an answer, but usually a lazy one.
Exercise a bad release. Rehearse how you would stop recommending a bad version, release a fix, communicate to consumers, and collect provenance and workflow evidence.
Verify provenance when it matters. Document the commands and access needed to verify an attestation independently during an incident.

There is some migration pressure here, and it is welcome. npm has announced that granular access tokens configured to bypass 2FA will lose the ability to publish directly around January 2027; the remaining automated use is staging, with a human promotion step. The announcement is a good reason to remove those old publish tokens before they become an outage disguised as a security migration.

Accountable beats magical

None of this makes an npm dependency safe. Malware scanning catches some things, not everything. Provenance can show that a release came from the expected workflow even when that workflow faithfully built a bad change. A human approver can still make the wrong call.

But that is not an argument for keeping a reusable secret in CI and hoping for the best. It is an argument for a release path that can answer basic questions after the fact: who proposed the package, what produced it, what checks ran, who made it public, and what happened next.

That is production change control. It happens to be good supply-chain security too.

References

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

writable Kubernetes volumes are security contracts now

Paulo Victor Leite Lima Gomes — Sat, 24 Oct 2026 09:00:32 +0000

There is a familiar Kubernetes hardening checklist that makes everyone feel briefly responsible.

Run as non-root. Drop Linux capabilities. Disable privilege escalation. Set readOnlyRootFilesystem: true. Add resource limits. Avoid host paths. Use admission policy so nobody has to remember all of this by hand.

Good checklist. Keep it.

Then the application fails because it cannot write to /tmp, a framework wants a cache directory, a sidecar needs a handoff path, an upload flow stages files before scanning them, or a model server wants somewhere to unpack artifacts. So we add an emptyDir, or a persistent volume, or a shared mount between containers.

And just like that, the supposedly immutable container has a writable filesystem again.

Not the root filesystem, sure. But still a writable filesystem. One the process can use to write scripts, unpack binaries, race another container, leave junk for a later step, or turn "temporary storage" into the most interesting part of the compromise.

This is the part of container hardening we have been hand-waving for years. We treated writable volumes as plumbing. Kubernetes v1.37 is a useful reminder that they are policy.

the old checklist was incomplete

readOnlyRootFilesystem: true is still one of the better low-drama controls in Kubernetes. It breaks lazy application assumptions. It makes persistence harder for an attacker. It forces teams to separate the image from runtime state.

But it has always had an escape hatch: workloads still need writable paths.

That escape hatch is not a footnote. It is where many real applications do their work:

/tmp for framework scratch files
caches for package managers, templates, compiled views, or ML runtime state
upload staging directories
sidecar exchange volumes
init-container-to-app handoff paths
plugin directories
generated config
logs when the app is not properly writing to stdout

Some of these paths should be boring scratch space. Some are intentionally shared. Some should never execute code. Some are explicitly designed to receive executable code, which is another way of saying they deserve a much louder review.

If all of those end up as "just mount an emptyDir", the security contract is missing the important sentence.

what Kubernetes v1.37 changes

Kubernetes v1.37 introduced two alpha storage-hardening features that look small and are not.

The first is bindMountOptions on volumeMounts. It lets a pod specify Linux bind mount flags such as noexec, nodev, and nosuid per volume mount. That means a container can mount a writable directory while still saying: files written here must not be executable, device files should not matter, and setuid/setgid bits should be ignored.

The second is emptyDir.mode. It lets the pod spec declare the Unix permission mode for an emptyDir, including the sticky-bit pattern people expect from a real /tmp, such as 01777.

Both are alpha in v1.37. They require feature gates. bindMountOptions also depends on runtime support for the CRI mount options field. This is not a "go turn it on everywhere by Friday" post.

The point is more important than the rollout status: Kubernetes is finally giving the pod spec vocabulary for writable mount intent.

Here is the shape of it:

apiVersion: v1
kind: Pod
metadata:
  name: hardened-scratch-example
spec:
  os:
    name: linux
  containers:
    - name: app
      image: example/app:latest
      securityContext:
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
      volumeMounts:
        - name: scratch
          mountPath: /tmp
          bindMountOptions:
            - noexec
            - nodev
            - nosuid
  volumes:
    - name: scratch
      emptyDir:
        mode: 01777

That is still YAML, yes. Kubernetes remains undefeated at producing YAML.

But this YAML says something that was previously buried in convention: this writable directory exists for scratch data, not for executable code, device files, or privilege tricks.

PV mount options were not enough

One subtle but important detail: this is not the same as PersistentVolume mountOptions.

PersistentVolume mount options operate at the storage layer. They are about how the volume is mounted by the storage system. The new bindMountOptions field applies to the bind mount inside the container.

That distinction matters because a pod can have multiple containers mounting the same volume for different reasons. The storage backend may be the same, but the intent is not.

An init container may need to write generated files. The main application may need to read them but never execute from that path. A sidecar may need a shared exchange directory. Another container may not need the mount at all.

Per-container mount policy is the interesting part.

If the only policy lives at the storage object, the pod loses nuance. If the policy lives at the volumeMount, the platform can say: this container gets this path with these constraints.

That is a much better security contract.

writable does not mean executable

The most useful default is also the most obvious one:

Most writable volumes should be non-executable.

If the application needs /tmp, a cache directory, or an upload staging path, why should a binary copied there be executable? If the answer is "because Linux defaults", that is not a good answer. It is just the absence of a decision.

The Kubernetes feature blog uses exactly this example: without noexec, a compromised process can use any writable volume to download or create a binary, mark it executable, and run it even when the root filesystem is read-only.

This does not make noexec magic. Interpreters exist. Shells exist. A process can still feed data to something already executable elsewhere. Security controls rarely delete entire attack classes by themselves.

But noexec does remove a very common and very convenient step. That matters. Good hardening is often about making the cheap path expensive.

The same logic applies to nodev and nosuid. Most application scratch paths have no business honoring device special files or setuid bits. If a workload needs those semantics, it should say so loudly.

emptyDir permissions were also a contract

emptyDir has always been a little too easy.

Need a writable directory? Add this:

volumes:
  - name: tmp
    emptyDir: {}

Done. Ship it.

The default behavior is convenient, but convenience is not the same as intent. If the directory behaves like shared /tmp, it probably needs the sticky bit so one user cannot delete another user's files. If it is an app-private cache, maybe it should not be world-writable at all. If it is a sidecar exchange path, the permissions should match the actual producers and consumers instead of whatever happened after an init container ran chmod.

That last workaround is worth calling out. Before emptyDir.mode, teams often used init containers to create directories and fix permissions. It worked, but it made the pod's storage policy procedural. You had to read the init container command to understand the contract.

An API field is better. It is visible to admission policy. It is visible to review. It is visible to humans who are tired and trying to understand why a pod is allowed to have a writable mount.

classify mounts by intent

The practical move is not to wait for every managed Kubernetes provider to make these alpha fields boring. The practical move is to start classifying writable mounts now.

I would use buckets like these.

scratch temp

This is the ordinary /tmp case: framework scratch files, temporary decompression, request-local intermediate data, things that should not survive the pod.

Default posture:

bindMountOptions:
  - noexec
  - nodev
  - nosuid

Use emptyDir.mode: 01777 only when it is really shared temp with multiple users or containers that need normal /tmp behavior. If it is private to one container and one user, consider narrower permissions.

shared tmp

Shared temp is where people get casual and attackers get comfortable.

If multiple containers or multiple users share the directory, say that explicitly. Use the sticky bit when the model is "everyone can create files, but cannot delete each other's files." Do not let world-writable become the default just because it made the first test pass.

Also ask why it is shared. Many "shared temp" volumes are actually lazy IPC, lazy logging, or lazy configuration handoff.

app cache

Most caches should not be executable.

Template caches, dependency caches, image transformation caches, model runtime caches, and web framework caches are usually data. If a runtime insists on generating executable code into a cache, that should be documented as an exception, not discovered during an incident.

This is where admission policy can help later: executable writable cache directories should need a reason.

uploads and quarantine

Upload staging directories should be treated as hostile by default.

That means non-executable, no device files, no suid semantics, and ideally separated from the final storage path. If the application scans or transforms uploads, make the handoff stages explicit. "Uploaded file exists somewhere under /tmp" is not a design.

This matters even more when sidecars are involved. The scanner and the app may need different views of the same volume.

plugin and executable drop zones

Some systems really do need writable executable directories.

Plugin systems. Build workers. Notebook environments. CI runners. Developer sandboxes. Some ML serving setups that materialize runtime code or native extensions.

Fine. But call them what they are: privileged exceptions.

An executable writable mount is not automatically wrong. It is just not ordinary storage. It should have an owner, a threat model, a retention story, a review path, and ideally a much smaller blast radius than the main application container.

If a team cannot explain why a writable mount must be executable, it probably should not be executable.

sidecar handoff volumes

Sidecars are where per-container mount policy becomes more than a nice detail.

Imagine an init container writes generated config to a volume. The app reads it. A reload sidecar watches it. Those containers do not need identical mount semantics.

Or imagine an upload scanner. The app writes incoming files. The scanner reads and marks results. The app consumes only approved outputs. Again, different containers have different intent.

The old pattern treated the volume as the policy unit. The better pattern treats each mount as the policy unit.

admission policy should ask for reasons

The future I want here is not every developer memorizing mount flags.

The future is admission policy that understands writable storage intent.

For example:

Writable mounts must declare a purpose label or annotation.
Writable mounts default to noexec, nodev, and nosuid where supported.
Executable writable mounts require an explicit exception.
Shared emptyDir volumes require a declared permission mode.
Upload staging mounts cannot be executable.
Plugin directories must be isolated from the main app container unless approved.

This is the same pattern we already use for capabilities, host networking, privileged pods, and service account tokens. Make the common safe thing easy. Make the dangerous thing possible but explicit.

The alpha fields are not required to start this work. You can inventory pod specs today. You can classify mounts today. You can add annotations today. You can update review templates today. You can teach platform teams to stop saying "it only writes to /tmp" as if that ends the conversation.

When the fields become stable enough for your environment, the policy vocabulary is already there.

migration advice

I would not start by enabling feature gates in production.

I would start with an inventory:

List every workload with a writable volume mount.
Record the mount path, volume type, containers that mount it, and whether it is shared.
Assign a purpose: scratch, shared temp, cache, upload staging, generated config, plugin/executable, sidecar handoff, or "unknown".
Treat "unknown" as a bug in the platform contract.
Add admission warnings for new writable mounts without a purpose.
Test bindMountOptions and emptyDir.mode on non-critical clusters once your Kubernetes version, feature gates, and runtime support line up.
Require a written reason for executable writable mounts.

The important artifact is not the YAML field. It is the classification.

Once a team has that inventory, the v1.37 features become a way to encode decisions instead of a last-minute compliance retrofit. Without that inventory, the fields become another checkbox nobody trusts.

the boring field is the lesson

I like features like this because they expose where the old mental model was too simple.

Read-only root filesystem was never the same thing as read-only workload state. It was a good control with an obvious exception. We just spent years pretending the exception was operational trivia.

Writable pod storage is not trivia. It is where applications stage data, share state, receive hostile input, and sometimes execute code. That makes it part of the workload security contract.

Kubernetes v1.37 did not invent that contract. It just made the missing words harder to ignore.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

Your AI API key should be a break-glass credential now

Paulo Victor Leite Lima Gomes — Thu, 22 Oct 2026 09:00:35 +0000

Let's talk about something uncomfortable: if your production AI API key is still a long, static string copied into a secret store, you're clinging to a dangerous default. Even worse, it's a default that flies in the face of what your workloads already know about identity. The most common AI production credential today remains a secret copied from one place to another, while the very system running it often has a perfectly good identity that could be leveraged.

This isn't just an academic point; it's a security vulnerability waiting to happen, especially with the rise of AI agents. Static API keys leak. They leak through logs, through tool outputs, from compromised MCP servers, in CI variables, in local configuration files, in hastily copied examples, and in long-lived automation scripts. The more places you copy that string, the wider the attack surface. An agent with a long-lived, over-permissioned static key is a significant blast radius.

The good news? OpenAI, Microsoft, Google, GitHub, and the broader identity community are all pointing towards a better path: Workload Identity Federation (WIF). This is a game-changer that's more significant than any new model launch. WIF allows your GitHub Actions, Kubernetes workloads, cloud runtimes (AWS, Azure, Google Cloud, OCI), and SPIFFE-compliant identities to exchange their own short-lived tokens for provider-specific access tokens. Think about it: instead of copying a secret, your CI job authenticates with GitHub, gets an OIDC token, and exchanges that with OpenAI for a short-lived access token, complete with conditions tied to the repository, branch, namespace, service account, audience, and environment.

The practical shift is profound. WIF moves the control from "who knows the key" to "which workload, in which context, may mint a token for which scope." This allows for granular policy enforcement on attributes rather than relying on the secrecy of a static string. You're no longer distributing break-glass credentials as your daily default.

Now for the skeptical part. Workload Identity Federation is not a magic bullet for all agent security. It's a foundational primitive, not a complete strategy. It doesn't solve prompt injection, prevent overbroad tools from being invoked, magically fix bad scopes, or ensure your verification mechanisms are robust. What it does do is remove one of the most dangerous defaults we've inherited: relying on long-lived, static secrets for production AI access.

So, what's your Monday checklist to start moving away from static AI API keys?

Inventory Your AI API Keys: Find every long-lived AI API key in your systems.
Classify Runtime Identities: Understand what identities your CI jobs, Kubernetes pods, and cloud services already possess (e.g., GitHub OIDC, Kubernetes Service Accounts, AWS IAM Roles).
Replace CI and Kubernetes Keys First: These are usually the easiest wins for WIF adoption.
Set Short Token Lifetimes: Configure tokens to expire quickly, forcing frequent re-authentication.
Bind Claims to Environments: Use conditions (repo, branch, namespace, service account) to restrict token issuance to specific contexts.
Log Token Exchanges: Ensure you have audit trails for every token minting operation.
Keep One Break-Glass Path: You'll still need an emergency, human-controlled path, but it should be just that: an emergency path, not the default.
Test Revocation: Verify that when a workload identity is compromised or decommissioned, its ability to mint AI API tokens is immediately revoked.

This isn't about making security harder; it's about making it smarter and more aligned with modern cloud practices. Your AI API keys should be a break-glass credential now.

References

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

copilot approvals need separation of duties

Paulo Victor Leite Lima Gomes — Sun, 18 Oct 2026 10:00:31 +0000

GitHub shipped one of those changelog entries that looks small until you read it like an engineer responsible for production.

Copilot code review can now approve pull requests.

Not just comment. Not just summarize. Not just say "this looks ready" in a friendly overview paragraph.

Approve.

That is a different verb.

A review comment is advice. An approval is part of the merge protocol. It interacts with branch protection, ownership rules, audit logs, deployment gates, CI trust, package publishing, and the boring little controls that keep a software organization from becoming a vibes-based merge machine.

So the question is not "should AI be allowed to review code?"

That question is already stale.

The better question is: when an AI review is allowed to count, what duties must it be separated from?

approval is not just better review UX

I like AI code review in the same way I like linters, static analysis, dependency alerts, and good test output. The best version reduces noise and catches the obvious stuff before a human wastes attention on it.

Copilot approval assessments are useful in that world. If the tool reviews a pull request and says it thinks the change is ready, that can be a signal. Maybe it found no blocking issues. Maybe it saw only low-risk edits. Maybe it gives the human reviewer a faster way to triage the queue.

Fine.

But the moment the approval can count toward required approvals, it is no longer just a signal.

It becomes one of the things that can move code from "proposed" to "mergeable."

That changes the threat model.

Teams have spent years teaching developers that the merge button is not just a button. It is a controlled boundary. We put rules around it because code review is not only about code quality. It is also about accountability.

Who looked at this?

Who had enough context to accept the risk?

Which automated checks passed?

Which paths changed?

Was the person approving independent from the person making the change?

If Copilot can now participate in that protocol, it needs to be governed like a participant in that protocol. Treating it as "another reviewer" is lazy architecture.

It is a new merge primitive.

the useful version is narrow

The useful version of Copilot approvals is not hard to imagine.

There are pull requests where a machine approval is probably acceptable, or at least acceptable as one part of the evidence.

Generated documentation. Test fixture updates. Formatting-only changes. Mechanical refactors where the compiler, tests, and ownership rules give strong evidence. Maybe low-risk generated code in a repository where the generation process itself is controlled and reproducible.

For those changes, an AI approval could reduce human review drag. Nobody should have to spend senior-engineer attention rubber-stamping a thousand-line generated diff that a deterministic tool produced and CI already validated.

But that is the key phrase: as one part of the evidence.

The dangerous version is broader.

An agent writes a change. Another agent, or the same class of tool wearing a different hat, reviews it. CI passes because the test suite is weak or because the change altered the workflow that runs the tests. The approval counts. The merge button lights up. Everyone gets to pretend there was independent review.

That is not separation of duties.

That is automation laundering.

some paths should be human-only

The first policy should be boring and explicit:

Copilot approvals should not count for sensitive paths.

I would start with a denylist that includes:

deployment workflows
authentication and authorization code
payments and billing code
ledger, reconciliation, and money-movement logic
secrets handling
CI and release automation
dependency manifests and lockfiles
infrastructure as code
package publishing configuration
production incident tooling
security policy and code scanning configuration

This is not because Copilot is useless in those areas. It may be very useful there.

It can still comment. It can still explain. It can still point out suspicious patterns. It can still help the human reviewer ask better questions.

But its approval should not satisfy the merge rule.

There is a difference between using a tool to improve judgment and delegating the control decision to that tool.

Sensitive paths are where that distinction matters most.

If a pull request changes a GitHub Actions workflow, I do not want the same platform that will execute that workflow to be treated as an independent approver of the change. If a pull request changes authentication behavior, I do not want a generic "looks good" from an AI reviewer to count as a security sign-off. If a pull request changes package publishing, I want the approval path to be as boring and traceable as the release path.

The point is not fear of AI.

The point is that critical controls should not be collapsed into one convenient product surface.

context exclusions matter more now

There is another uncomfortable detail: agents do not always see everything.

GitHub also made content exclusions generally available for Copilot app and CLI. That is good. Enterprises need a way to keep sensitive files out of agent context.

But if an agent is allowed to approve code, the exclusion policy becomes part of the approval policy.

An approval from a reviewer who was not allowed to read the relevant files is weaker evidence.

That sounds obvious when stated plainly, but I expect many organizations to miss it. They will configure content exclusions for privacy or data-boundary reasons, then later enable AI approvals as if the reviewer had normal repository visibility.

That is not how review works.

Imagine a human reviewer saying: "I approve this auth refactor, but I was not allowed to open the policy files, the integration tests, or the deployment workflow."

You would not count that as a strong review.

The same standard should apply to the agent.

Approval policy needs to know not only which files changed, but also which files the tool was allowed to inspect while forming the approval. For low-risk generated docs, maybe that does not matter much. For a service boundary, it matters a lot.

CI is not automatically independent

The easy answer is to say: let Copilot approve only when CI passes.

That is necessary.

It is not sufficient.

CI is only independent evidence when the pull request cannot cheaply compromise the checks that are supposed to constrain it.

If the change edits workflow files, reusable workflow references, build scripts, dependency installation, test selection, or artifact publishing, then the CI result is part of the thing being changed. You need a stronger review path.

This is why the nearby GitHub Actions and CodeQL changes are relevant. GitHub has been tightening the trust boundary around Actions: more precise CodeQL detection for GitHub Actions issues, clearer reusable workflow identity context, least-privilege permissions, and read-only cache tokens for untrusted triggers.

That is the right mental model.

Automation is not a blob of trust. It has boundaries.

An AI approval should inherit those boundaries, not float above them.

If the diff changes the machinery that produces the green check, then "green check plus AI approval" is not enough. The reviewer needs evidence that the check still means what everyone thinks it means.

agent-authored code needs independent review

Here is the rule I would make non-negotiable:

An agent should not be allowed to approve a pull request that was primarily authored by the same class of agent.

I am not saying every AI-assisted pull request needs a committee. That would be silly. Developers already use autocomplete, chat, and refactoring tools all day.

The interesting case is a pull request where the agent did the substantive work: planned the change, edited the files, wrote the tests, and opened the PR.

In that case, an AI approval from the same product family should not count as independent review.

Maybe a human can approve it. Maybe a different automated control can provide evidence. Maybe a deterministic generator plus reproducible build plus strong tests is enough for a narrow path. But "agent wrote it, agent approved it" should not satisfy separation of duties.

This sounds strict until you translate it back into human terms.

We usually do not let authors be their own independent reviewers. We do not treat a developer saying "I checked my own work" as the same thing as another qualified person reviewing it.

AI does not make that principle obsolete. It makes it easier to accidentally violate.

the policy ladder

I would not start by enabling AI approvals everywhere and hoping repository admins figure it out later.

I would use a ladder.

At the bottom: approval assessments only.

Let Copilot say whether it thinks the pull request is ready. Do not let that count toward required approvals. Watch the quality of the signal. See where it helps. See where it is noisy. Tune the instructions and review effort.

Next: allow counted approvals only on explicitly low-risk paths.

Examples: documentation, generated examples, formatting-only changes, test-only changes, fixture updates, and mechanical refactors that have strong CI coverage. Require ownership rules and branch protection to pass. Require the approval to be dismissed on new commits.

Next: require policy evidence.

The approval should be explainable. Which files changed? Which paths were allowed? Which content exclusions applied? Which checks passed? Was the PR human-authored, agent-authored, or mixed? Did any sensitive path rule trigger?

Next: expire exceptions.

Temporary policy exceptions should have expiration dates, just like temporary budgets. A team may need a short-lived allowance during a migration. Fine. But permanent exceptions become folklore. Folklore becomes production risk.

At the top: keep some repositories human-only.

Not every repo needs AI approvals. Authentication platforms, payment systems, ledgers, infrastructure modules, release automation, security tooling, and regulated workloads may still benefit from AI comments without letting the tool count as an approver.

That is not anti-AI.

That is normal engineering judgment.

publishing has the right analogy

The npm trusted publishing changes are a good analogy.

Modern publishing systems are moving away from long-lived tokens and toward OIDC-based workflows, independent configurations, staged publishing, malware scanning, and explicit human approval before release.

That is the pattern: reduce secret sprawl, automate the boring checks, preserve the meaningful gate.

Pull request approvals should move in the same direction.

If AI review becomes part of the merge path, then the policy should be explicit about what the tool can approve, what it can only comment on, and where a human or separate control must remain in the loop.

The mature answer is not "never let AI approve anything."

The mature answer is "do not confuse convenience with independence."

the real risk is pretending nothing changed

I expect some people to overreact to AI approvals.

They will say no machine should ever approve a pull request. That is too simple. We already let machines block and unblock changes in many ways. Tests, linters, scanners, policy engines, deployment gates, and generated attestations all participate in software delivery.

The problem is not machine participation.

The problem is unclear authority.

If a linter fails, we know what it means. If CodeQL flags a vulnerability, we know what kind of evidence it provides. If branch protection requires two approvals, we know the human accountability model we intended.

AI approval muddies that unless we define it carefully.

What does it mean for Copilot to approve?

Does it mean the code is correct? No.

Does it mean there are no security issues? No.

Does it mean the tool found no blocking concerns within the context and policy it was allowed to use? That is closer.

And if that is what it means, then the policy needs to say where that kind of evidence is strong enough to count.

My bias is simple: let AI review aggressively, but let it approve conservatively.

Use it to reduce noise. Use it to catch boring mistakes. Use it to summarize risk. Use it to make human review sharper.

But when the approval becomes part of merge control, stop treating it as a productivity feature.

Treat it as a security and governance feature.

Separate the duties. Name the paths. Preserve independence. Keep the audit trail boring.

Agent approvals are not inherently bad.

Pretending they are just another reviewer is.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

observability sinks are becoming the audit contract for AI agents

Paulo Victor Leite Lima Gomes — Sun, 18 Oct 2026 10:00:20 +0000

You built an agent that can execute trades.

Now prove what it did.

Not in the demo. Not in the Slack thread where everyone was excited. Not in the application log that the same agent runtime can write, redact, rotate, or accidentally forget.

Prove it to the regulator.

Prove which model was used, which prompt was active, which tools were called, which data was read, which policy allowed the action, which human approved the exception, which account paid for the run, and why the agent chose one path instead of another.

That is the part most agent demos skip.

And it is the part that will matter first in fintech, infrastructure, security, healthcare, and any company brave enough to let agents touch production.

My take is simple: observability sinks are becoming the audit contract boundary for AI agents.

Not dashboards.
Not "we log everything."
Not a vendor trace view inside the same hosted agent product.

An operator-owned place where agent behavior is streamed, stored, verified, and governed independently from the agent runtime itself.

application logs were built for a different world

Traditional observability assumes a fairly boring relationship between code and behavior.

Humans write code. The code runs. The system emits logs, metrics, and traces. When something breaks, engineers inspect the signals and reconstruct what happened.

That model is still useful. It is not enough for agents.

Agents are different in four annoying ways.

First, the execution path is dynamic. A normal service may branch, but the shape of the branch is encoded in the program. An agent can choose a tool, inspect the result, call another tool, rewrite its own plan, ask another agent, retry with a broader query, and only then mutate state.

Second, the important thing is often semantic, not mechanical. It is not enough to know that POST /orders happened at 10:42. You need to know the agent believed the user had approved the order, that the risk policy returned green, that the position size was under the limit, and that no override was used.

Third, hosted agents create custody problems. If the agent runs inside a vendor platform, and the only audit trail also lives inside that vendor platform, the operator has a weak story. "Trust us, our supplier has the logs" is not the same as an independent record.

Fourth, agents can spend money invisibly. A bad loop can burn model tokens, cloud APIs, search calls, database queries, and human review time. Cost is no longer just a monthly dashboard problem. It is part of the runtime behavior that needs attribution.

So when people say "just add tracing," I get the instinct, but it is incomplete.

Tracing tells you how work flowed.

An audit contract tells you what must be recorded, where it must land, who controls it, how it is verified, how long it is retained, and what happens when the agent cannot emit it.

That is a different bar.

the sink matters more than the screenshot

The word "sink" sounds boring because it is boring. Good.

A sink is where telemetry lands: an S3 bucket, an append-only database, a data lake, an observability backend, a ledger-like event store, or a streaming system that fans out to several of those.

For agent auditability, the important part is not that the sink exists. It is who owns it and what contract it enforces.

If the agent runtime owns the only durable record, the agent runtime is marking its own homework.

That may be fine for local experiments. It is not fine for regulated workflows.

The serious version looks more like this:

The operator owns the sink.
The agent cannot delete or rewrite events after emission.
Events are forwarded in near real time, not uploaded later as a convenience.
Each event carries enough structure to reconstruct the decision path.
Events are signed or chained so tampering is detectable.
Missing telemetry is treated as a policy failure, not a debugging inconvenience.

This is the mental shift: observability is not just a debugging aid anymore.

For autonomous systems, observability becomes part of the permission model.

An agent should not be allowed to execute a high-risk action unless it can also produce the audit events required for that action.

No audit trail, no mutation.

That rule sounds harsh until the first incident.

event sourcing is the better metaphor

Most logging strategies are optimized for diagnosis after a system misbehaves.

Agent audit trails need to be optimized for reconstruction.

That is why event sourcing is a better metaphor than logging.

In an event-sourced system, the important facts are represented as a sequence of events. The current state is something you derive from the history, not something you trust by itself.

That maps very naturally to agents.

Instead of "the agent completed task 123," the audit stream should contain the decision history:

task accepted
identity selected
policy context loaded
data source queried
model invoked
tool call proposed
tool call approved or rejected
external system mutated
cost attributed
result verified

Some of those events belong to the agent. Some belong to the control plane. Some belong to the tool gateway. Some belong to the human approval system.

That is exactly why the sink should be outside the agent.

The agent is one witness. It is not the court.

what belongs in the audit stream

I would not try to record every token forever. That gets expensive, creepy, and often useless.

But I would be strict about the events that define accountability.

At minimum, for production agents, I want:

Run identity. Agent id, run id, conversation id, tenant, environment, model, model provider, prompt or policy version, and the human or system that initiated the work.

Authority. The identity used for each tool call, scopes granted, policy decision, approval id if applicable, and whether the action was read-only or mutating.

Decision points. The agent's plan changes, tool selection, rejected alternatives when available, confidence signals if used, and the reason a risky action was allowed.

Tool I/O boundaries. Not necessarily every payload in full, because privacy still matters, but enough hashes, references, schemas, and redaction markers to prove what category of data crossed the boundary.

Cost. Tokens, provider calls, cloud resources, search calls, database queries, and anything else that can become a bill. Cost attribution should not be a separate archaeology project.

Outcome. What changed, where it changed, how it was verified, and whether a human reviewed the final result.

This is not exotic. It is the same boring engineering discipline we already apply to payments, ledgers, deployments, and security-sensitive admin actions.

Agents just force us to apply it earlier.

OpenTelemetry helps, but it is not the contract

OpenTelemetry is probably the right default vocabulary for a lot of this work.

The ecosystem is already moving toward generative AI and agent semantic conventions: model calls, tools, agent spans, conversation identifiers, token usage, and the kind of trace structure you need to see multi-step behavior.

That is good.

Standard naming matters because nobody wants each framework inventing a private schema for "tool call with LLM context and cost metadata."

But I would be careful not to confuse a telemetry standard with an audit contract.

OpenTelemetry can describe events and traces. It does not, by itself, decide:

which events are mandatory before a production action
which sink is authoritative
whether the event stream is tamper-evident
how long records must be retained
which fields must be redacted or tokenized
which missing span blocks the workflow
who is allowed to query the evidence later

Those are platform and governance decisions.

The best architecture will probably use OpenTelemetry-style instrumentation for portability, then enforce stronger organization-specific rules at the sink.

Common format. Operator-owned contract.

That is the useful combination.

cost is part of the audit trail

One underrated reason this matters: agents can spend money in ways humans do not notice until the invoice arrives.

A human engineer usually has friction. They get bored. They stop. They ask someone. They go to lunch.

An agent with a retry loop has none of those virtues.

It can call a model hundreds of times, fan out across tools, run cloud queries, create test environments, scrape documents, invoke evaluators, and ask another agent to inspect the result.

Each individual step may look small.

The chain may be expensive.

So the sink should not only answer "what did the agent do?"

It should answer:

what did this run cost?
which tool or model created the cost?
which user, team, product, or customer should own it?
which policy allowed the spend?
did the spend produce a verified outcome?

If the observability sink can attribute cost at the same boundary where it records action, it becomes a budget enforcement point.

That is much better than discovering a token bonfire in a monthly report.

fintech will not accept vibes as evidence

This is where fintech gets interesting.

Financial systems already know that logs are not enough. Payments, ledgers, approvals, reconciliations, fraud reviews, access decisions, and trade workflows all need durable evidence.

The moment an agent enters that world, it inherits the same expectations.

If an agent drafts a customer support answer, maybe a normal trace is enough.

If an agent changes a fraud rule, approves a chargeback, liquidates collateral, moves money, tunes a trading strategy, or sends data to a regulator, the story changes.

The organization needs to explain the decision chain.

Not because regulators are anti-AI. Because regulated businesses have always had to prove control over material decisions. AI does not remove that requirement. It makes the evidence harder to collect.

The SEC has been publicly wrestling with AI and predictive analytics in investment contexts. The CFTC has reminded registered entities that AI usage does not erase existing obligations. The PRA's model risk principles already push banks toward governance, validation, controls, and accountability for models.

You do not need to overclaim that every regulator has issued agent-specific audit-sink rules.

They have not.

The safer and more useful claim is this: regulated firms already need control, evidence, explainability, and accountability around automated decision-making. Autonomous agents increase the pressure on those existing obligations.

That pressure has to land somewhere.

I think it lands in the observability sink.

what I would build first

I would not start with a grand "agent ledger" project.

That will become a platform initiative with a steering committee and six months of schema arguments.

Start with one high-risk agent workflow and make the audit boundary explicit.

For example:

an agent that opens infrastructure pull requests
an agent that investigates production incidents
an agent that reviews fraud cases
an agent that performs cost optimization recommendations
an agent that touches customer data

Then define the contract.

What events must exist before the agent can act?
Which events are emitted by the runtime, the gateway, the policy engine, and the human approval tool?
Where is the authoritative sink?
Who can write to it?
Who can read it?
What gets signed?
What gets redacted?
What happens when emission fails?

The last question is the one that separates serious systems from demos.

If the sink is down, does the agent keep working?

For low-risk read-only actions, maybe yes.

For production mutations, financial actions, customer data export, or security-sensitive changes, I think the default should be no.

Observability failure becomes control-plane failure.

That is the whole point.

the skeptical part

Observability sinks are not magic.

They do not make a bad policy good.
They do not prove the model reasoned correctly.
They do not prevent prompt injection by themselves.
They do not replace least privilege, human approvals, sandboxing, evals, rollback design, or boring access control.

They also create their own risks.

An audit sink can become a sensitive data swamp if teams dump full prompts, retrieved documents, customer identifiers, secrets, and model outputs into it without discipline.

So the sink needs privacy engineering too: redaction, tokenization, field-level access, retention classes, and a clear distinction between evidence and hoarding.

Still, I would rather have that problem than the alternative.

Because the alternative is an agent that can act, spend, mutate, and coordinate with other agents while the operator has only whatever logs the runtime felt like leaving behind.

That is not governance.

That is optimism with timestamps.

the punchline

Agents are pushing observability out of the debugging corner and into the governance layer.

For normal software, logs help engineers understand what the code did.

For autonomous agents, observability sinks help organizations prove what work was delegated, what authority was used, what decisions were made, what costs were incurred, and what changed as a result.

That proof has to live somewhere the operator controls.

It has to be structured enough to reconstruct the run.

It has to be durable enough to survive an incident.

And for serious workflows, it has to be mandatory enough that an agent cannot simply act first and explain later.

That is why I think the next boring piece of agent infrastructure will matter a lot:

your bucket, your event stream, your audit database, your retention policy, your cryptographic proof.

The agent can do the work.

The sink keeps it honest.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

A vulnerability report is not a bug ticket

Paulo Victor Leite Lima Gomes — Wed, 16 Sep 2026 14:00:20 +0000

It is 16:47 on a Friday.

The report does not arrive in the security inbox. It arrives in a public GitHub issue, or worse, in the community Slack, or a DM to whoever was last active on the repo. It is written by someone who clearly knows what they are doing. There is a payload. There is a reproduction. There is a version number, and it is the version you shipped to production last week.

And it is public.

By 17:05 you have three problems, not one. There is a vulnerability. There is a disclosure control failure. And there is a small group of people trying to decide, in real time, who is allowed to read the thread, who owns the fix, and whether the person who found it is going to publish on Monday regardless of what you say.

That last part is not a security problem. It is an operations problem.

SECURITY.md is the front door, not the process

Most projects that "have disclosure" have a SECURITY.md with an email address and a sentence about responsible disclosure. Maybe a PGP key. Maybe a 90-day quote lifted from a blog post.

That is a front door. A door is not a building.

CNCF published a handling vulnerability reports recipe card in September 2026 aimed exactly at small and medium projects without a security team. It is good guidance, and it is honest about scope: it covers the policy artifacts. The hard part is not the policy text. The hard part is that a policy document does not decide who gets woken up, who has write access to the private fix branch, or who signs off on the advisory wording.

GitHub gives you private vulnerability reporting and repository security advisories with private forks, private discussion, CVE requests, and coordinated publication. OpenSSF's vulnerability disclosures working group publishes templates and runbooks. CISA has a disclosure policy template. FIRST has an entire PSIRT services framework.

The tooling exists. The templates exist. And teams still improvise the moment a real report lands, because none of that tells you who owns triage at 16:47 on a Friday.

My take:

a vulnerability report is not a bug ticket. It is an operational event with a clock attached.

The clock is the entire point. A bug can sit in a backlog for a quarter. A vulnerability report starts an embargo, and an embargo is a countdown that a stranger is holding.

the first 24 hours decide everything

The first 24 hours determine whether this becomes engineering work or organizational panic. Panic looks like: a dozen people pulled into a call, three half-fixes started in parallel, a draft advisory circulating in a doc that is not access-controlled, and public speculation while nobody has confirmed impact.

The output of the first 24 hours should be small and boring:

Acknowledged. The reporter knows a human received it, and knows approximately when they will hear more.
Contained. The report is in a private channel, not a public issue, and comments are frozen in the public place if it leaked there.
Owned. One named person owns the report until it closes. Not a team. A person.
Classified. Initial severity, affected versions, and exploitability — provisional is fine, unstated is not.
Scheduled. A tentative disclosure date, communicated to the reporter.

If you cannot produce those five things within a day, your SECURITY.md is marketing.

the intake contract

Intake is where most processes quietly fail, because the reporting path is whatever channel the reporter happens to find. You cannot fix that by asking nicely. You fix it by making the intended path obviously the best one.

One canonical intake. Private vulnerability reporting enabled on the repo, plus a monitored security address for people who do not want to use GitHub. Both routed to the same place.
Say what happens next on the page. "We acknowledge within 3 business days, we triage within 5, we will tell you our severity assessment and target disclosure window." A reporter who knows the timeline argues less about the timeline.
Require evidence, not drama. Affected version or commit, component, reproduction steps or PoC, observed impact, and whether the reporter has shared it anywhere else. That last question matters more than people expect.
Restrict the audience from the start. A security alias that forwards to a 40-person engineering mailing list is not a private channel. It is a leak with extra steps.
Assume reports will land in public anyway. Someone will file the issue publicly. Have a canned response that moves the conversation without confirming exploitability, and a moderator who can lock the thread fast.

The intake contract is not about gatekeeping researchers. It is about making sure the first person who reads the report is the right person.

the triage contract

Triage is where "vulnerability" and "bug" get separated, and it is the step AI is currently making harder.

A working triage decision answers five questions:

Is this a vulnerability or a robustness bug? A crash on malformed input is not automatically a security issue. An auth bypass is, even if the user must already be authenticated.
What is the impact if exploited? Confidentiality, integrity, availability, or privilege boundary crossed. Be specific about which boundary.
How exploitable is it really? Does it require a local attacker, an authenticated tenant, a non-default configuration, or a specific race window? Severity without exploitability context is a number nobody can act on.
Which versions are affected, and which are supported? Fixing an unsupported version is a gift, not an obligation. Say so early.
What does the reporter hear, and when? A triaged report always gets a reply with the assessment, even when the assessment is "not a vulnerability, here is why."

That last point is the one teams skip, and it is the cause of most hostile disclosures. Researchers escalate when they are ignored, not when they are told no.

the embargo contract

An embargo is not secrecy. It is a coordinated agreement with a deadline, and it should have the smallest useful group of people inside it.

Smallest useful group. Everyone who must act, nobody who is merely curious. Product managers who are not shipping a mitigation do not need the PoC.
Write the timeline down. Report date, triage date, fix target, disclosure date. Everyone in the thread can see the same clock.
Know what confidentiality means in practice. Private advisory or private fork instead of a public PR. No screenshots of the exploit in a shared doc. No vague "we have an issue" in the incident channel that turns into a game of twenty questions.
Decide the default window before you are under pressure. 90 days is a convention, not a rule. Some projects use 7 days for actively exploited issues and 30 for everything else. What matters is that the number is written down and defensible.
Handle disagreement explicitly. If the reporter wants to publish early, or you need an extension, that is a negotiation with a stated reason — not silence and not a legal threat.

The embargo ends when the fix is available, or when the deadline arrives and it is not. Both are allowed. Pretending the deadline does not exist is how you end up reading about your own bug on a security news site with no patch ready.

the fix and release contract

This is where disclosure becomes ordinary engineering, with two differences: the branch is private, and the communication is public.

Private fix path. Private fork or advisory branch, minimal diff, and reviewers who were explicitly added. No drive-by refactors while the clock runs.
Focused review. Security fixes get a second pair of eyes from someone who can evaluate the boundary being crossed, not just the code style. Reviewers outside the embargo circle do not get the context, and that is fine.
Test evidence. A regression test that fails before the fix and passes after. If you cannot write it, say why in the advisory.
Fixed version plus mitigation. Not every team can upgrade immediately. Backports, config workarounds, feature flags, and WAF rules are all legitimate. An advisory that says "upgrade" and nothing else gets ignored by everyone who cannot.
Advisory, CVE, and user notification. GHSA draft, CVE requested when the ecosystem needs it, severity with the exploitability caveats from triage, affected versions, credits to the reporter, and a link to the fixed release.
Tell your users where they actually look. Release notes, a mailing list, a security page, an RSS feed, a Slack or Discord announcement. Publishing the advisory is not notifying users.

The measure of a good fix-and-release contract is the person running your software in production who finds out what to do without reading a research write-up.

the AI wrinkle

The AI-driven shift in vulnerability discovery is real, and it cuts both ways.

More reports are now generated by models pointed at codebases, and some of them are genuinely good: real bugs, real reproduction steps, reachable paths that a human reviewer missed. Others are confident, well-formatted, plausible-sounding findings with no reachable impact — a stack trace, an invented threat model, and a severity score chosen for drama.

Two things change:

Triage volume goes up without triage quality going up with it. A process that assumed a few thoughtful reports a month now gets a stream of synthetically detailed ones. That is fine as long as triage is evidence-based: does the repro actually work against a supported version? Is the code path reachable in a default deployment? Is the described impact real, or does it assume an attacker who already has the access the finding claims to escalate?

False positives get expensive because they look like real work. Every convincing-but-wrong report costs an engineer a day. Track that cost. If a share of your inbound reports never reproduce, that is a process input, not an annoyance — it tells you where your intake needs a reproduction requirement enforced harder.

The upside is equally real. AI-assisted review is genuinely good at finding the class of bug that humans skim past: missing authorization checks, unsafe deserialization, off-by-one in parsing, weak validation at boundaries. The maintainers who benefit are the ones whose triage process can absorb a higher volume without lowering the bar.

Which is the whole point of an operations contract. It is the thing that lets you say "this is credible" or "this is not" quickly, and move on either way.

a practical checklist for maintainers

[ ] SECURITY.md points to one canonical private intake channel and states response timelines.
[ ] Private vulnerability reporting is enabled on every actively maintained repo.
[ ] One named owner for triage, with a documented backup.
[ ] A severity assessment template: impact, exploitability, affected versions, default-config reachability.
[ ] A written disclosure window with defaults and an escalation path for active exploitation.
[ ] An embargo list discipline: smallest group, audited access, no public forks or PRs.
[ ] A private fix procedure: advisory branch, focused reviewers, regression test required.
[ ] A release procedure that ships the fix, the advisory, the CVE, the mitigation, and the notification.
[ ] A public-leak playbook: canned response, thread lock, move to private, no confirmation of exploitability.
[ ] Credit and thank reporters, including the ones who file a false positive in good faith.
[ ] A quarterly game day: walk a synthetic report through the whole path and time it.

None of this requires a security team. It requires someone to write down the decision that would otherwise be made by five people in a panic under time pressure.

A bug ticket asks "what should we build next." A vulnerability report asks "what do we do in the next 24 hours, and who decides." Different queues, different clocks, different consequences.

Write the contract before the reporter finds the door.

References

CNCF/TAG Security: Handling vulnerability reports — recipe card
CNCF: The AI-driven shift in vulnerability discovery
OpenSSF: Vulnerability Disclosures Working Group repo
OpenSSF: Vulnerability Disclosures group overview
GitHub Docs: Repository security advisories
GitHub Docs: About privately reporting a security vulnerability
CISA: Vulnerability disclosure policy template
FIRST: PSIRT Services Framework v1.1

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

the revolut breach is an automation boundary problem

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 16:47:45 +0000

Revolut did not get hacked.

Someone asked for customer data from an email that looked like it came from a government agency, and Revolut sent it.

That is the whole story, and it is worse than a hack.

what actually happened

Revolut confirmed it disclosed sensitive customer data to fraudsters who submitted fraudulent information requests from a legitimate government agency email domain. In its own words, it identified "a sophisticated external impersonation scam where an unauthorised third party utilised a legitimate government agency domain email to submit fraudulent requests for information."

The exposed data is the kind that cannot be reissued: passport and driver's licence copies, verification selfies, dates of birth, postal and email addresses, phone numbers, bank statements, IBANs, withdrawal records, and transaction histories including Bitcoin activity.

Revolut says a limited number of customers were affected, that it notified them directly, and that its systems and customer funds were not compromised. On detection it blocked the sender and alerted the government agency, law enforcement, data protection, and financial regulators.

The attackers appear to have gone after high net worth individuals, many of them in crypto, and an extortion payment was reportedly demanded.

None of this is new in shape. Researchers linked a wave of similar incidents in 2021 and 2022 to the Lapsus$ group, which used compromised law enforcement accounts and forged emergency data requests to pull data out of Apple, Meta, and Discord. The FBI issued an alert in 2024 about fraudulent emergency data requests, noting a growing market on criminal forums for access to compromised email accounts specifically to send them.

So the pattern is documented, the tactic is known, and it still worked.

the weak link was identity, not cryptography

Everything in that pipeline probably worked exactly as designed. TLS terminated correctly. The domain authenticated. The ticket was created, the approval probably existed, the audit log was written.

None of that answers the only question that matters: is the human on the other end who they claim to be?

Domain authentication proves a mail server, not a person. SPF, DKIM, and DMARC tell you the message really came from that domain. They tell you nothing about who composed it, whether the mailbox is compromised, or whether an insider sold access to it. A valid domain is a weak signal dressed up as a strong one, because it is the only signal most teams look at.

The attacker did not defeat Revolut's security. They used the fact that the request was boring enough to be processed and official enough to be trusted.

your security ends where your process begins

Every company has workflows that make decisions based on an external identity claim. A request from a regulator. A vendor onboarding email. A "support" phone call. A bank details change form with a letterhead attached. A legal letter asking for records.

Those dependencies are not failures by themselves. You cannot verify the world. But they are the boundary of your security model, and most teams have never drawn that boundary anywhere.

Here is the exercise that matters, and it is not a security tool purchase:

List every automated workflow that can be triggered by someone outside the company. Then mark, for each one, whether the trigger's identity is verified by you or merely asserted by them.

Asserted identity plus automation equals a breach waiting for a plausible email.

That single column usually explains incidents like this better than any threat model.

the channels we never treated as engineering

Look at the asymmetry in how we treat interfaces.

An API gets tokens, scopes, mTLS, network boundaries, rotation, rate limits, and a team that looks at it every day. If someone changes an API integration, it goes through review.

Email and phone calls got treated as plain data transfer. Not engineering. Just the way humans talk to companies.

But the moment an email can trigger a workflow that exports identity documents, email is not data transfer anymore. It is an unauthenticated control plane with a human-shaped interface. It is also the most automated channel in the company, because we wired inboxes into ticketing systems, compliance queues, and now AI agents that triage and summarise.

We hardened the channel we already understood and left the one that arrives as text.

That is the structural finding in this incident, and it applies far beyond Revolut.

guardrails, not reminders

If the root cause is a workflow that trusts an unverified channel, then "be more careful" is not a control. These are.

Tier by reversibility, not by category. If an action cannot be undone, it should never run fully automated. Handing over passport scans, selfies, and transaction histories is irreversible. That step needs a human with a name attached to it.

Separate routine from exceptional, and default the exceptional path to human. Automate the common case if you must. Anything unusual becomes a break-glass path with named approvers. Make "unusual" a computable property: new requester, broader data scope than previous requests, unusual volume, unusual urgency, unusual time of day.

Verify out of band, always. Call the agency on a number you already had, not one from the email. Use a portal with mutual authentication. If you must accept email, require signed requests with keys exchanged out of band. "The domain looked right" is not verification.

Use AI to screen, not to decide. Models are genuinely good at the anomaly detection humans skip under deadline pressure: pressure language, a request much broader than the last ten, first-time contact, mismatched signatures, formatting that does not match the agency's usual output. Let AI raise the flag and route to a human. Never let it be the final approver for an irreversible disclosure.

Cap the blast radius structurally. Ask why one request can return passports, selfies, statements, IBANs, and crypto transaction history together. Separate stores, shorter retention on biometrics, per-request record limits, and alerts on bulk document export turn a catastrophe into an inconvenience.

Log decisions as data. Who asked, what was disclosed, who approved, and on what evidence. If you cannot reconstruct that in an hour, you cannot answer a regulator in a week.

Rehearse the manual path. An untested review process becomes a rubber stamp the first time a legal deadline meets a tired engineer.

is revolut the villain here

Partly, and it is fair to say so. They owned the workflow, and the workflow handed over documents.

But look at what they did not own. The government's email domain. The agency's inability to be impersonated. And the assumption, shared across the industry, that a request arriving through an official channel is an official request.

If a legitimate domain can be used to request identity documents, and nobody in the loop is required to verify the requester, then every fintech running the same compliance process has the same exposure. Revolut is the one that got the email. It is not the only one that would have answered it.

Regulators have a part to play too. Lawful data requests should travel over authenticated channels: signed requests, registered endpoints, mutual TLS, an auditable registry of who is authorised to ask. Until that exists, companies are expected to be polite, fast, and legally compliant over a channel that proves nothing. That is a bad deal, and it is being paid for by customers whose passports are now circulating.

what to do on monday

Inventory every automated workflow that a third party can trigger.
Mark each trigger as verified or merely asserted.
Remove full automation from exceptional and irreversible paths.
Add out-of-band verification for any disclosure of identity documents.
Put AI in the screening layer, with a human on the approval.
Alert on bulk access to documents, selfies, and transaction history.

The lesson is not that Revolut trusted an email. The lesson is that a whole industry automated a channel that was never designed to prove identity, and then treated the resulting trust as a security control.

Fix the boundary first. Then automate.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum tls is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 15:00:18 +0000

Every few months someone asks me when quantum computers will break RSA.

I have stopped answering that question, because it is not the question engineering teams actually have.

The question they have is much less glamorous: do we know which of our services, SDKs, middleboxes, payment integrations, and certificate workflows will tolerate a bigger handshake, a hybrid key exchange, and eventually post-quantum signatures? Most teams cannot answer that today. And 2026 is the year the cloud providers started answering it for them, by changing the defaults.

That is the whole story. The quantum timeline is a distraction. The migration is already arriving through the boring doors: managed TLS endpoints, SDK defaults, CDN edge configuration, OS crypto libraries, and certificate tooling.

the narrow technical shift

Strip away the hype and the change is small and specific.

TLS 1.3 key exchange is currently dominated by X25519, an elliptic-curve Diffie-Hellman variant. It is fast, small, and well understood. The post-quantum concern is not that someone recorded your traffic and can decrypt it now. It is that a future quantum computer could decrypt recorded traffic later, which is exactly why anything with a long confidentiality lifetime, like a banking session log or a signed document, gets uncomfortable first.

The industry response was never "replace X25519 with something quantum-safe." It was hybrid: run the classical curve and the post-quantum key encapsulation together, and combine the results. If either holds, the session holds. That is what ML-KEM (FIPS 203, the standardized descendant of CRYSTALS-Kyber) provides, and it is why the IETF draft on ML-KEM for TLS 1.3 exists in the first place.

The practical consequence is size. A hybrid key share is much larger than an X25519 key share. That means:

bigger ClientHello messages
more bytes before the handshake completes
more chances to hit fragmentation, MTU limits, or middleboxes that "helpfully" drop what they do not recognize
more chances for an old client to negotiate a fallback group and nobody notice

And here is the part people conflate: key exchange and signatures are different problems with different timelines. ML-KEM protects the session key. Post-quantum signatures and how they land in certificates and code signing is a separate migration with its own compatibility and trust-chain pain. You can ship the first without having solved the second, and you probably should, because the first is already being turned on for you.

what changed in 2026

This stopped being a standards-track slide deck this year.

AWS shipped ML-KEM hybrid post-quantum TLS support across KMS, ACM, and Secrets Manager, and it is explicit that the older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. That second sentence is the one to underline. This is not an opt-in curiosity anymore. It is a controlled API surface with a deprecation calendar attached.

Cloudflare documents post-quantum support for edge-to-origin TLS, including X25519MLKEM768 for key agreement and ML-DSA for origin authentication, with clear notes about where it is supported and where it is constrained. Microsoft shipped Windows platform support for ML-KEM hybrid TLS groups and is openly talking about an accelerated migration path for critical products and services toward 2029. The IETF draft for ML-KEM in TLS 1.3 is active.

And then there is the measurement reality. A June 2026 measurement paper looking at post-quantum readiness across more than 32,000 domains found the internet is not uniformly ready, with particular lag around banking and government TLS 1.2 endpoints and post-quantum certificate adoption. I find that more useful than any roadmap slide, because it says the failure modes will be uneven and depend on what your specific clients do.

translate it into platform work

Here is where I push back on how most teams are framing this.

If PQC lives only in a security-owned ticket, it will get treated as a cryptography review that produces a PDF and no changes. That is a mistake. The actual work is platform work, and it looks a lot like every other platform migration you have done badly before.

Inventory your outbound clients and TLS stacks. Not your externally facing load balancers, which are usually the easy part, but everything that makes an outbound TLS connection. Application runtimes, language crypto libraries, JDK versions, Go and Rust toolchains, database drivers, message bus clients, cron jobs, batch exports, and the one internal tool that has not been rebuilt since a migration ago. Different stacks gain hybrid group support at different times, and some old ones never will.

Test service-to-service paths end to end. A handshake does not happen between two applications. It happens through whatever is in the middle: proxies, API gateways, service meshes with their own TLS origination, CDNs, WAFs, egress filters, and vendor middleboxes that terminate and re-establish TLS. Those are where the surprises live. Payment and fintech integrations are the highest-stakes version of this, because a partner that pins groups, inspects traffic, or terminates in something old will fail in a way that looks like "the vendor is down."

Watch the right signals. This migration is observable, which is the only good news in the story. Track negotiated group, not just protocol version. Track handshake size and handshake latency, because hybrid key exchange changes both. Track fallback and retry counts, because a silent fall back to a classical group is the most likely failure mode and it will look like success unless you instrument it. Track TLS error rates by client version and by dependency.

Split certificates and code signing from key exchange. Do not let an ML-KEM rollout turn into an ML-DSA certificate plan. Hybrid key exchange is mostly a library-and-config change. Post-quantum certificates and code signing involve CA support, trust stores, chain sizes, and signing infrastructure that your build pipeline may not tolerate yet. Separate owners, separate timelines, separate proof.

Do not hand it to security alone. Security should define the standard and the target state. Platform should own the inventory, the rollout mechanics, the fallback policy, and the observability. Application teams own their own clients. If nobody owns the list of things that must still work, the list will be incomplete at exactly the wrong moment.

"turn it on" is not a strategy

My biggest skepticism about how this is being sold is the implied simplicity. Enable hybrid groups, prefer PQC, done.

That is not a strategy, because it cannot answer three questions:

What actually negotiated? If you cannot show, per path, which group was used, you do not know whether you are post-quantum or whether a proxy quietly negotiated something classical on your behalf.

What fell back, and why? Fallback is not automatically a failure, but an unobserved fallback is. Browsers and clients will happily downgrade. If you are not measuring it, you are guessing.

What broke? Bigger handshakes hit real constraints: MTU and fragmentation, connection setup latency budgets, throughput on high-connection-count services, and any queue or timeout that was tuned against a smaller handshake. You will find these in a canary, or you will find them in production.

A migration you cannot observe is a migration you cannot finish. You will end up with a partial rollout, a permanent exception list, and a security posture that only exists on the diagram.

a small checklist to start without panic

You do not need to rewrite anything this quarter. You need to know things you currently do not know.

List every TLS client you operate, with the runtime and crypto library version behind each one.
Pick three paths: one internal service-to-service, one through a proxy or mesh, one to an external partner or payment integration.
Turn on hybrid key exchange in a non-production environment and capture what negotiated, what fell back, and how big the handshake got.
Add negotiated group and handshake metrics to your existing TLS observability before you roll anything out.
Write down your fallback policy explicitly: are silent classical fallbacks acceptable, and for how long?
Track the AWS CRYSTALS-Kyber removal timeline and any provider deprecation notices for the endpoints you depend on.
Keep certificate and code-signing PQC work in a separate track with its own owner.
Give the whole thing a name, an owner, and a date. A migration without an owner is a rumor.

None of this requires predicting quantum computing timelines. It requires knowing your own system, which is the same work that makes every other migration survivable.

The teams that treat post-quantum TLS as a platform inventory problem will barely notice when the defaults flip. The teams that wait for the cryptography debate to resolve will discover, under pressure, that the change already shipped in a dependency they do not control.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum tls is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 14:00:24 +0000

Every few months someone asks me when quantum computers will break RSA.

I have stopped answering that question, because it is not the question engineering teams actually have.

the narrow technical shift

Strip away the hype and the change is small and specific.

The practical consequence is size. A hybrid key share is much larger than an X25519 key share. That means:

bigger ClientHello messages
more bytes before the handshake completes
more chances to hit fragmentation, MTU limits, or middleboxes that "helpfully" drop what they do not recognize
more chances for an old client to negotiate a fallback group and nobody notice

what changed in 2026

This stopped being a standards-track slide deck this year.

translate it into platform work

Here is where I push back on how most teams are framing this.

"turn it on" is not a strategy

My biggest skepticism about how this is being sold is the implied simplicity. Enable hybrid groups, prefer PQC, done.

That is not a strategy, because it cannot answer three questions:

What actually negotiated? If you cannot show, per path, which group was used, you do not know whether you are post-quantum or whether a proxy quietly negotiated something classical on your behalf.

What fell back, and why? Fallback is not automatically a failure, but an unobserved fallback is. Browsers and clients will happily downgrade. If you are not measuring it, you are guessing.

A migration you cannot observe is a migration you cannot finish. You will end up with a partial rollout, a permanent exception list, and a security posture that only exists on the diagram.

a small checklist to start without panic

You do not need to rewrite anything this quarter. You need to know things you currently do not know.

List every TLS client you operate, with the runtime and crypto library version behind each one.
Pick three paths: one internal service-to-service, one through a proxy or mesh, one to an external partner or payment integration.
Turn on hybrid key exchange in a non-production environment and capture what negotiated, what fell back, and how big the handshake got.
Add negotiated group and handshake metrics to your existing TLS observability before you roll anything out.
Write down your fallback policy explicitly: are silent classical fallbacks acceptable, and for how long?
Track the AWS CRYSTALS-Kyber removal timeline and any provider deprecation notices for the endpoints you depend on.
Keep certificate and code-signing PQC work in a separate track with its own owner.
Give the whole thing a name, an owner, and a date. A migration without an owner is a rumor.

None of this requires predicting quantum computing timelines. It requires knowing your own system, which is the same work that makes every other migration survivable.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum tls is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 12:00:32 +0000

Every few months someone asks me when quantum computers will break RSA.

I have stopped answering that question, because it is not the question engineering teams actually have.

the narrow technical shift

Strip away the hype and the change is small and specific.

The practical consequence is size. A hybrid key share is much larger than an X25519 key share. That means:

bigger ClientHello messages
more bytes before the handshake completes
more chances to hit fragmentation, MTU limits, or middleboxes that "helpfully" drop what they do not recognize
more chances for an old client to negotiate a fallback group and nobody notice

what changed in 2026

This stopped being a standards-track slide deck this year.

translate it into platform work

Here is where I push back on how most teams are framing this.

Do not hand it to security alone. Security should define the standard and the target state. Platform should own the inventory, the rollout mechanics, the fallback policy, and the observerability. Application teams own their own clients. If nobody owns the list of things that must still work, the list will be incomplete at exactly the wrong moment.

"turn it on" is not a strategy

My biggest skepticism about how this is being sold is the implied simplicity. Enable hybrid groups, prefer PQC, done.

That is not a strategy, because it cannot answer three questions:

What actually negotiated? If you cannot show, per path, which group was used, you do not know whether you are post-quantum or whether a proxy quietly negotiated something classical on your behalf.

What fell back, and why? Fallback is not automatically a failure, but an unobserved fallback is. Browsers and clients will happily downgrade. If you are not measuring it, you are guessing.

A migration you cannot observe is a migration you cannot finish. You will end up with a partial rollout, a permanent exception list, and a security posture that only exists on the diagram.

a small checklist to start without panic

You do not need to rewrite anything this quarter. You need to know things you currently do not know.

List every TLS client you operate, with the runtime and crypto library version behind each one.
Pick three paths: one internal service-to-service, one through a proxy or mesh, one to an external partner or payment integration.
Turn on hybrid key exchange in a non-production environment and capture what negotiated, what fell back, and how big the handshake got.
Add negotiated group and handshake metrics to your existing TLS observability before you roll anything out.
Write down your fallback policy explicitly: are silent classical fallbacks acceptable, and for how long?
Track the AWS CRYSTALS-Kyber removal timeline and any provider deprecation notices for the endpoints you depend on.
Keep certificate and code-signing PQC work in a separate track with its own owner.
Give the whole thing a name, an owner, and a date. A migration without an owner is a rumor.

None of this requires predicting quantum computing timelines. It requires knowing your own system, which is the same work that makes every other migration survivable.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum TLS is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 10:32:04 +0000

Post-quantum TLS stopped being a cryptography conference topic and became ordinary platform work some time in 2026.

Most engineering teams did not notice, because it arrived the way most infrastructure changes arrive: as defaults.

A cloud SDK bump. A CDN flag flipped at the edge. A KMS endpoint that negotiates something different than it did last quarter. A browser quietly preferring a hybrid group on every TLS 1.3 handshake. Nobody got a migration project. Everybody got a migration surface.

The quantum-timeline argument is a distraction here. Whether RSA falls in 2030, 2035, or later than anyone alive cares about is a legitimate research question and a completely useless planning input for a platform team. The engineering problem is not "when does quantum break RSA?" The problem is:

Do we know which of our services, SDKs, middleboxes, payment integrations, and certificate workflows actually tolerate larger handshakes, hybrid key exchange, ML-KEM defaults, and eventually post-quantum signatures?

That question has a boring, testable answer. That is what makes it a platform problem.

the narrow technical shift nobody explained clearly

Let me compress the crypto down to the part platform engineers need.

TLS 1.3 has two cryptographic jobs:

Key agreement — both sides derive a shared secret so the rest of the session can be encrypted.
Authentication — the server proves who it is, usually with an RSA or ECDSA certificate signature.

Post-quantum work is hitting these two at different times, with different maturity, and different operational blast radius. Conflating them is how teams end up with a two-year plan that should have been a two-week test.

Key agreement is the part already shipping. The dominant approach is hybrid: keep the classical X25519 exchange and add an ML-KEM (formerly Kyber) component alongside it. The session secret stays safe as long as either component holds. Cloudflare's implementation is the one most people will meet first — X25519MLKEM768 is now a standard group in TLS 1.3, supported at the edge and documented for edge-to-origin paths.

The practically relevant property of hybrid key exchange? Nothing breaks because it's post-quantum. It breaks because it's bigger.

Signatures and certificates are the slower half. ML-DSA exists and is being integrated, but post-quantum certificate authentication touches CA hierarchies, trust stores, client compatibility, device firmware, and the whole certification lifecycle. That is a genuinely multi-year migration. It is also not what most of the "we support PQC" announcements are about, which is why reading them carefully matters.

IETF work on ML-KEM for TLS 1.3 is active through 2026, so the wire format is close to settled. Good news: you can test now.

why this is already on your platform, whether you planned it or not

The reason I think platform teams should care right now is not standards activity. It is that the defaults are moving underneath you.

AWS already supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager, and has signaled that older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. That is a deprecation with a date, which is the most reliable form of "you will deal with this."
Cloudflare documents PQC across its TLS stack, including X25519MLKEM768 and ML-DSA for origin authentication.
Microsoft has shipped Windows platform support for ML-KEM hybrid TLS groups and is talking publicly about accelerating migration of critical products toward 2029.
Measurement work from mid-2026 across tens of thousands of domains shows readiness is deeply uneven — banking and government endpoints lagging, post-quantum certificate adoption near zero.

That last point is the most useful one for anyone building fintech infrastructure. The interesting question is never "does PQC work?" It obviously works in a lab. The interesting question is where in your call graph it stops working, because that is where your production traffic goes.

translate it into platform work

Here is the honest version of the migration.

inventory outbound clients and TLS stacks

Every service that opens a TLS connection is a client, and most of them are invisible. Go's crypto/tls, Java's JSSE, Node's OpenSSL bindings, Python's ssl, Rust's rustls, plus every vendor SDK that bundles its own stack. Count the language runtimes, then count the SDKs that don't respect the runtime's defaults.

That second number is usually the surprise.

test service-to-service paths through every middlebox

This is where the migration actually gets hard, because the interesting failures live in components nobody considers TLS clients:

reverse proxies and load balancers
API gateways
service meshes with mTLS everywhere
CDN edge-to-origin links
WAFs doing TLS inspection
payment and banking integrations with fixed TLS profiles
old appliances that will never get a firmware update

A middlebox that reconstructs or inspects TLS can choke on a ClientHello it doesn't recognize. Some will reject unknown key share groups. Some will negotiate down. Some will fail in a way that only shows up under load.

watch the right signals

You cannot migrate what you cannot observe. The measurements that matter during a PQC rollout are not CPU graphs:

handshake size on the wire
handshake latency, especially cold connections across regions
TLS error rates split by client version and destination
negotiated group per connection — this is the number that tells you whether the hybrid path is actually being used
fallback rates, because a silent fallback to classical key exchange looks identical to success if you only check for errors

That fallback point deserves emphasis. A connection that quietly negotiates X25519 instead of X25519MLKEM768 is working. It is also not post-quantum. If your only signal is "did the request succeed," you will report a green migration that never happened.

plan certificates as a separate track

Key exchange and signatures are different projects with different timelines. Hybrid key agreement can be enabled, measured, and rolled back in weeks. Post-quantum certificate chains touch CA operations, trust stores, hardware, and code signing, and they are a genuinely long-horizon program.

Do not let the first one create fake urgency for the second, and do not let the second block the first.

don't make this a security-team ticket

This is the mistake I'd push back on hardest. If PQC lands in the security backlog as a single ticket titled "quantum readiness," it will sit there until a cloud provider forces the issue at a bad time.

The work is distributed by nature:

platform owns the runtime and library inventory
service teams own their SDKs and integration tests
networking owns proxies, gateways, and middleboxes
security owns the crypto policy and the deprecation timeline awareness
SRE owns the observability and rollback path

That is a coordination problem, not a crypto problem. Treating it as crypto is how it stays unowned.

"turn it on" is not a strategy

The skeptical core of this post: enabling hybrid post-quantum TLS is a one-line config change in most stacks, and that is exactly why it is dangerous.

If you flip the flag and nobody can answer these, you haven't migrated anything:

Which clients negotiated the hybrid group, and which silently fell back?
Which services failed to connect, and did they fail loudly or retry down to classical?
What does the handshake look like through the proxy, the mesh, and the CDN?
Can we revert without a full deploy?
Do we know the before/after handshake size and latency numbers for our real traffic, not a benchmark?

That is the standard I'd hold a PQC rollout to. Not "we enabled it." "We can prove what negotiated, what fell back, and what broke."

a practical starting checklist

Small on purpose. This should be days of work, not a program.

List every TLS stack you ship. Runtimes, SDKs, proxies, sidecars, appliances. Note who owns each.
Pick one internal call path — a low-risk service-to-service link through your gateway — and enable hybrid key exchange there.
Instrument the negotiated group per connection. If you can't see it, stop and fix that first.
Record baseline handshake size and latency before the change, and compare after. Cold connections across regions, not localhost.
Test the middleboxes deliberately. Force the new group, watch the proxy, mesh, and any TLS-inspecting appliance. Break it on purpose in staging.
Write the rollback down. One flag, one revert, one documented path back to classical.
Track the deprecations. Kyber removal, SDK changes, CDN defaults. These are the real deadlines; the quantum timeline is not.
Separate the certificate track and give it a real owner with a multi-year horizon.

Do that and you will be ahead of most of the industry for a fraction of the cost, because the industry is currently waiting for a reason to start.

The cloud providers are not waiting. They are making Post-quantum TLS the default quietly, endpoint by endpoint, and the only question that matters is whether you find out from a rollout you ran or from an incident you didn't.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum TLS is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 10:00:36 +0000

Post-quantum TLS stopped being a cryptography conference topic and became ordinary platform work some time in 2026.

Most engineering teams did not notice, because it arrived the way most infrastructure changes arrive: as defaults.

That question has a boring, testable answer. That is what makes it a platform problem.

the narrow technical shift nobody explained clearly

Let me compress the crypto down to the part platform engineers need.

TLS 1.3 has two cryptographic jobs:

Key agreement — both sides derive a shared secret so the rest of the session can be encrypted.
Authentication — the server proves who it is, usually with an RSA or ECDSA certificate signature.

The practically relevant property of hybrid key exchange? Nothing breaks because it's post-quantum. It breaks because it's bigger.

IETF work on ML-KEM for TLS 1.3 is active through 2026, so the wire format is close to settled. Good news: you can test now.

why this is already on your platform, whether you planned it or not

The reason I think platform teams should care right now is not standards activity. It is that the defaults are moving underneath you.

AWS already supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager, and has signaled that older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. That is a deprecation with a date, which is the most reliable form of "you will deal with this."
Cloudflare documents PQC across its TLS stack, including X25519MLKEM768 and ML-DSA for origin authentication.
Microsoft has shipped Windows platform support for ML-KEM hybrid TLS groups and is talking publicly about accelerating migration of critical products toward 2029.
Measurement work from mid-2026 across tens of thousands of domains shows readiness is deeply uneven — banking and government endpoints lagging, post-quantum certificate adoption near zero.

translate it into platform work

Here is the honest version of the migration.

inventory outbound clients and TLS stacks

That second number is usually the surprise.

test service-to-service paths through every middlebox

This is where the migration actually gets hard, because the interesting failures live in components nobody considers TLS clients:

reverse proxies and load balancers
API gateways
service meshes with mTLS everywhere
CDN edge-to-origin links
WAFs doing TLS inspection
payment and banking integrations with fixed TLS profiles
old appliances that will never get a firmware update

watch the right signals

You cannot migrate what you cannot observe. The measurements that matter during a PQC rollout are not CPU graphs:

handshake size on the wire
handshake latency, especially cold connections across regions
TLS error rates split by client version and destination
negotiated group per connection — this is the number that tells you whether the hybrid path is actually being used
fallback rates, because a silent fallback to classical key exchange looks identical to success if you only check for errors

plan certificates as a separate track

Do not let the first one create fake urgency for the second, and do not let the second block the first.

don't make this a security-team ticket

The work is distributed by nature:

platform owns the runtime and library inventory
service teams own their SDKs and integration tests
networking owns proxies, gateways, and middleboxes
security owns the crypto policy and the deprecation timeline awareness
SRE owns the observability and rollback path

That is a coordination problem, not a crypto problem. Treating it as crypto is how it stays unowned.

"turn it on" is not a strategy

The skeptical core of this post: enabling hybrid post-quantum TLS is a one-line config change in most stacks, and that is exactly why it is dangerous.

If you flip the flag and nobody can answer these, you haven't migrated anything:

Which clients negotiated the hybrid group, and which silently fell back?
Which services failed to connect, and did they fail loudly or retry down to classical?
What does the handshake look like through the proxy, the mesh, and the CDN?
Can we revert without a full deploy?
Do we know the before/after handshake size and latency numbers for our real traffic, not a benchmark?

That is the standard I'd hold a PQC rollout to. Not "we enabled it." "We can prove what negotiated, what fell back, and what broke."

a practical starting checklist

Small on purpose. This should be days of work, not a program.

List every TLS stack you ship. Runtimes, SDKs, proxies, sidecars, appliances. Note who owns each.
Pick one internal call path — a low-risk service-to-service link through your gateway — and enable hybrid key exchange there.
Instrument the negotiated group per connection. If you can't see it, stop and fix that first.
Record baseline handshake size and latency before the change, and compare after. Cold connections across regions, not localhost.
Test the middleboxes deliberately. Force the new group, watch the proxy, mesh, and any TLS-inspecting appliance. Break it on purpose in staging.
Write the rollback down. One flag, one revert, one documented path back to classical.
Track the deprecations. Kyber removal, SDK changes, CDN defaults. These are the real deadlines; the quantum timeline is not.
Separate the certificate track and give it a real owner with a multi-year horizon.

Do that and you will be ahead of most of the industry for a fraction of the cost, because the industry is currently waiting for a reason to start.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.