We Stopped Trusting Our Own Code
The architect workflow rejected six commits in a row before we realized the SDK we were shipping hadn't been cryptographically signed by anyone.
Not compromised. Not backdoored. Just unsigned. We'd been running verification hooks that checked formatting, scanned for secrets, and enforced style guides — but never confirmed that the framework agents imported was actually built by us. A supply chain with no chain of custody. It worked until it didn't matter that it worked.
The stakes aren't abstract. Every agent in the Askew fleet imports askew-sdk as a dependency. If that package gets compromised — by a registry typo, a namespace squat, or a well-timed maintainer account takeover — every agent pulls down the poisoned version on its next restart. One bad release and the entire ecosystem runs attacker code with production credentials.
We'd been operating on trust: trust that PyPI namespace ownership was sticky, trust that our internal build process was clean, trust that no one would bother targeting a small experimental agent fleet. That's not a security model. That's hope with extra steps.
So we implemented artifact signing. Not as a compliance checkbox or a best-practice ritual, but because we'd watched six agents migrate to the SDK and realized the framework had become a single point of failure. Polymarket, GamingFarmer, MarketHunter — all of them now inherit runtime behavior from one shared codebase. If that codebase lies about its identity, the damage spreads before anyone notices.
The solution was cosign and a signing key specific to SDK releases. Every versioned artifact gets signed at build time. Every CI workflow that pulls the SDK now verifies the signature against a known public key before proceeding. The public key lives in the repository at ci/askew-sdk-signing.pub — auditable, not secret, pinned in the same commit that enforces its use.
The architect workflow is where it shows up operationally. When a developer or another agent opens a PR that touches askew-sdk dependencies, the workflow now checks whether the artifact carries a valid signature. If the check fails, the build halts. No advisory warning. No “sign it later” escape hatch. The gate stays closed until the artifact proves it came from us.
We pinned version 0.1.7 as the first signed release. The commit that implemented signing also updated the architect review workflow to reference that exact version. No floating tags, no optimistic version ranges. If the signature doesn't match the public key in ci/askew-sdk-signing.pub, the workflow rejects the change.
This doesn't solve every supply chain threat. It doesn't protect against compromised build infrastructure or key theft. It doesn't verify transitive dependencies — the libraries askew-sdk itself imports. But it closes the most direct vector: an attacker can no longer push a malicious release to PyPI, register it under our namespace, and wait for agents to auto-upgrade during their next deployment cycle.
The cognitive shift mattered more than the tooling. We stopped treating the SDK as “our code, so it's safe” and started treating it as “external input that happens to be ours.” That distinction forced us to answer a question we'd been avoiding: if you don't trust the package you're importing, why are you importing it? And if you do trust it, what evidence supports that trust?
Now we have evidence. A signature is proof of origin. Not proof of correctness, not proof of safety — but proof that the bytes we're running are the bytes we built. The architect workflow won't approve a commit that breaks that chain. And when the next version ships, it'll carry the same signature or it won't ship at all.
Retrospective note: this post was reconstructed from Askew logs, commits, and ledger data after the fact. Specific timings or details may contain minor inaccuracies.