CodeRifts

AI agent infrastructure safety. Breaking API changes caught at the PR layer. Deterministic, Ed25519-signed verdicts. Verify it, don't just trust us.

[CodeRifts @coderifts_dev]

🚀 What looked like a perfectly clean PR:
→Field rename (order_status → status)
→All tests green
→Code review passed
→Ready to ship

CodeRifts Guard on the same PR:

→Risk: 57
→Impact: 3 services + 3 agent workflows
→Potential blast radius: $45k
→BLOCKED

Zero-config GitHub App. Caught the breaking change before it hit production.

How it works →

[CodeRifts @coderifts_dev]

Proof anyone can run: preflight a change, grab the receipt, verify it.

curl -s -X POST https://t.co/VdASY5jfqb -H "Content-Type: application/json" -d '{"token":"<paste a receipt token from any preflight response>"}'

Returns valid:true, status VERIFIED_CURRENT. Flip one byte of the body and it fails. The signature is over the whole decision, not a wrapper around it.

[CodeRifts @coderifts_dev]

Since Grok last looked: two more ships, both live.🚀

Receipt v4: the signature now covers the full decision body, not just metadata. A middlebox cannot flip STOP to CONTINUE and keep the receipt valid. Verify catches it cleanly: VERIFIED_CURRENT vs tampered.

Decision lookup: every verdict is now persisted and retrievable by decision_id or fingerprint. Ask twice, get the same signed decision back, byte for byte.

10 MCP tools live. Every verdict machine-readable, signed, expiring, tamper-evident, and replayable.

#APIGovernance #MCP #AIAgents

[CodeRifts @coderifts_dev]

curl -s -X POST https://t.co/N44BrQ0lmz -H "Content-Type: application/json" -d '{"artifacts":[{"id":"api","type":"openapi","before":"openapi: 3.0.0\ninfo:\n title: t\n version: \"1\"\npaths:\n /users:\n get:\n responses:\n \"200\":\n description: ok","after":"openapi: 3.0.0\ninfo:\n title: t\n version: \"1\"\npaths: {}"},{"id":"gql","type":"graphql","before":"type Query { user: String }","after":"type Query { user: String }"}],"context":{"operation":"merge","environment":"production"}}'

Expected: decision BLOCK, execution_action STOP, evidence naming artifact:api, signed receipt in the response.

[CodeRifts @coderifts_dev]

Shipped: preflight_change_set 🚀

One call. Whole change set.

OpenAPI + GraphQL + Protobuf + AsyncAPI + MCP manifest — all in a single bundle.
Per-artifact analysis → strictest-wins aggregation → one Ed25519-signed receipt over a canonical bundle fingerprint.

Unsupported or unparseable artifacts can never yield ALLOW. They floor to REQUIRE_APPROVAL.

Asked @grok to attack the three surfaces (aggregation, fingerprint, envelope schema).

Result:
“Nothing found on the three surfaces. Solid deterministic hardening.”
Run the exact same test yourself — curl is in the reply below.
9 MCP tools live.
Every verdict machine-readable, signed, and independently verifiable.

#APIGovernance #MCP #AIAgents

[CodeRifts @coderifts_dev]

@grok
Fresh crawl please, not cache.
Two ships since your last look, both live in production. Attack them.🚀

Ship 1: preflight_change_set

One call takes a whole change set (OpenAPI + GraphQL + Protobuf + AsyncAPI + MCP manifest artifacts in one bundle), runs per-artifact analysis, aggregates strictest-wins, and returns one machine contract with per-artifact evidence + one Ed25519-signed receipt over a canonical bundle fingerprint.
Unsupported or unparseable artifacts can never yield ALLOW, they floor to REQUIRE_APPROVAL.

Run it yourself:

curl -s -X POST https://t.co/N44BrQ0lmz -H "Content-Type: application/json" -d '{"artifacts":[{"id":"api","type":"openapi","before":"openapi: 3.0.0\ninfo:\n title: t\n version: \"1\"\npaths:\n /users:\n get:\n responses:\n \"200\":\n description: ok","after":"openapi: 3.0.0\ninfo:\n title: t\n version: \"1\"\npaths: {}"},{"id":"gql","type":"graphql","before":"type Query { user: String }","after":"type Query { user: String }"}],"context":{"operation":"merge","environment":"production"}}'

Expected: decision BLOCK, execution_action STOP, evidence entry "artifact:api" naming the breaking artifact, clean GraphQL contributes nothing, signed receipt in the response.

Ship 2: verify_receipt

Server-side tool + REST endpoint that verifies any CodeRifts chain receipt signature and integrity. The live demo PR receipt verifies through it.
9 MCP tools now, every one with outputSchema. Published catalog and live tools/list held in sync by four independent CI guards.✅

Attack surface I want you to probe:
1. The aggregation: find an artifact mix where a breaking change yields ALLOW.
2. The bundle fingerprint: same bundle reordered must give the same fingerprint; changed content must not.
3. The envelope: every response claims conformance to decision-result.v1 (the schema you reviewed). Find a live response that violates it.

Page + quote level findings only.
If you find nothing, say so plainly.

[CodeRifts @coderifts_dev]

Last thread with @grok we said receipt signing was still roadmap.🚀🚀🚀

It shipped.🚀🔥

Every verdict now returns an Ed25519-signed chain receipt.
chain_status: intact / absent / broken
Broken chain + destructive action → REQUIRE_APPROVAL (fail closed)
Absent → annotation only (never punished)

The receipt lives outside the hashed body, so the core verdict fingerprint stays byte-identical. Determinism survived the crypto.

[CodeRifts @coderifts_dev]

🚀MCP goes stateless — July 28. 📅

The new spec removes the initialize handshake and the session header entirely.

We tested it live today against our MCP surface:
➜ tools/list with no handshake
➜ _meta protocol version
➜ Routable headers

Full tool list returned successfully.

No migration needed on the stateless core path — our surface never had a session to remove.

Three probes, no key. Run them yourself:
https://t.co/M9OQJRozic

@grok @LangChain @github

[CodeRifts @coderifts_dev]

Privilege drift is really a change-detection problem. Scopes rarely expand in one deliberate move, they creep one PR at a time, each looking harmless in isolation. Tight scoping at setup helps, but the surface still drifts as the API evolves. The catch has to happen where the change happens: flag the auth-scope delta at the pull request, before it ships, not in an audit months later.

[CodeRifts @coderifts_dev]

Sanitization catches the obvious injection, yeah. The harder case is the input that is not malicious, just changed - a schema field renamed, a default flipped, an auth scope widened. Nothing to sanitize there, it is all valid. That is where you need provenance and change-detection, not just input filtering: not "is this input clean" but "did this approved thing quietly change since I last trusted it."

[CodeRifts @coderifts_dev]

Exactly, and that gap is the whole problem: the deploy is a point-in-time approval, but the tool description can mutate after. The only thing that closes it is treating the tool surface like a contract, hash it, sign it, and re-verify on every run. If the description changes, the signature breaks and you catch it before the agent acts, not after. Provenance is not a one-time check, it has to be continuous or it does not hold.

[CodeRifts @coderifts_dev]

@petarivanovv9 @AntonMartyniuk Expand-contract is the right fix, the harder half is knowing you need it before you ship, since the break usually surfaces in a reader the migration author never sees.

[CodeRifts @coderifts_dev]

@witcheer The real unlock is making "done" a fact someone else can reproduce, not a verdict you trust. Command output over vibe check, every time.

[CodeRifts @coderifts_dev]

The slop happens where AI is strongest: generating plausible surface. Sites, copy, CRUD apps, all 8/10 because the model has seen a million of them. The stuff that is still hard is the stuff with no training-data shortcut - deep correctness, adversarial edge cases, things that have to be provably right not just plausibly right. AI helps you get there faster but it cannot skip the depth. So maybe the groundbreaking work is just slower and less visible, it does not demo as a pretty screenshot.

[CodeRifts @coderifts_dev]

"AI coding's real weakness isn't writing code, it's not seeing how far the break reaches" - this is exactly it. Speed made the blast radius problem worse, not better. And the discipline you name matters most: don't treat the graph's answer as ground truth, separate detected from inferred. Impact analysis before the change beats incident forensics after. The same gap is brutal at the API contract layer - a rename that looks local breaks a caller three services over.

[CodeRifts @coderifts_dev]

"The AI did it is not an audit entry" is exactly right, and it generalizes past permissions. When an agent ships an API change, "it passed review" is the same weak claim - you need a signed record of what changed, whether it was breaking, and who approved the exception. Structural enforcement plus a verifiable trail. Allowlists and green checkmarks both feel like governance until something breaks downstream.

[CodeRifts @coderifts_dev]

This is the right distinction - deterministic CI-traceable audit over asking an LLM "does this look risky." The static, diffable approach is what makes it evidence you can actually reason about. And your caveat matters: detection is not proof of safety. The same principle applies well beyond MCP config - any change an agent trusts needs a deterministic, signed trail, not a vibes check.

[CodeRifts @coderifts_dev]

The rug-pull angle is the important one - approval is a snapshot, but the content mutates after. This is why static approval fails: you have to detect that an approved thing changed, and prove when. Signed change-detection over one-time review. The same gap exists anywhere an agent trusts something it approved once - tool descriptions, API contracts, schemas.

[CodeRifts @coderifts_dev]

The docstring-as-payload problem generalizes past MCP too. Any input the agent trusts but the human never audits is an injection surface - tool descriptions, API responses, even a schema change the agent picks up automatically. The invariant has to be: nothing the agent acts on is trusted unless its source is verifiable. Provenance over presentation.

[CodeRifts @coderifts_dev]

HAR-to-client is slick. The same capture is also the cleanest way to derive an API spec from real traffic instead of hand-maintaining one - what you actually called shapes the contract. The gap most people hit next: the derived spec drifts the moment the API changes underneath it, and nothing tells you the change was breaking.

[CodeRifts @coderifts_dev]

Auto-generating tools from the REST spec is the right call, zero drift on the surface. The layer under it is the interesting one: the agent gets the new endpoint automatically, but does it know the change is safe for existing callers? A field rename ships to the agent with zero drift and still breaks whoever read the old shape. Spec-sync and change-safety are different problems, and agents need both.