Two Ways to Give an Agent a Key

For: security architects, CISOs and DPOs, platform engineers, and anyone evaluating cryptographic identity for AI agents. Companion surfaces: the key-management lifecycle spec, REST Is Not GraphQL on why the integration layer belongs to you, Firmware, SBOM & the CRA for the evidence chain in practice, and the public verification endpoint at /.well-known/jwks.json.

If you are deciding what to actually build first: Server-Side Function Tools with AI Runners is the additive entry point — bounded functions that resolve authority per call and record themselves, with no migration to own. AI Trust Framework Requirements gives the ten requirements and the changes that close them without rewriting an endpoint; The Trust Framework is the same argument for a non-technical reader.

Block shipped Buzz on 21 July 2026: an open-source workspace where humans and AI agents hold cryptographic identities and every action is signed. It is a serious piece of work built on a serious thesis. This document compares its key-custody model with the one used here, because the difference is not cosmetic — it decides what can be proven, what happens after a compromise, and whether an enterprise security review can approve the thing at all. If you would rather try the mechanism than read about it, open the Channel Wizard — mint an attributed link or QR against a real product, free to preview, and watch the first scan land in a ledger you own.

The Channel Wizard, opened from a product page. The product is preselected and its MPN travels with the mint, so every scan keys to the identifier the product page already publishes. Previewing is free; minting unlocks with the add-on.

1. The shared thesis

Buzz is built on the Nostr protocol under Apache-2.0. Every participant — human or agent — holds a keypair that belongs to them rather than to the platform. Every message, workflow step, code event, and approval is stored as a cryptographically signed event, and the record is verifiable by anyone holding the public key.

That instinct is correct and worth stating plainly: agents are becoming actors, actors need identity, and identity without cryptography is just a label in someone's database.

We share the thesis and the primitive — Schnorr-family signatures over an append-only record. The divergence is what the key is for, and who holds it.

2. Identity is not authority

A signature answers one question: who did this? That is authorship. It proves an agent rather than a person acted, and proves the record was not altered afterward.

Commerce and compliance ask a different question first: was this actor allowed to do this, under what limit, with whose consent? A signed event reading "the agent spent $40,000" is a perfect record of an unauthorized purchase. Authorship tells you who to blame; authority tells you it could not have happened.

So the keys here sign a different object:

• Entitlements — capabilities are scoped, revocable grants held against a subject, resolved server-side on every call.
• Mandates — an agent acts under a signed grant carrying a spend cap, a scope, and an expiry.
• Consent binding — the certificate embeds the consent state as it stood at the moment of the grant, so a later dispute reads the terms that actually applied.

A verifier can therefore answer not just "did this actor sign it," but "was this actor entitled to it, and under what terms."

A familiar version of the same mistake — and why it persists

Consumer streaming built its access model on one shared password per household, then spent years trying to claw governance back with device fingerprints, address heuristics and verification prompts. Every one of those is a proxy inferring a fact the system never recorded: which person is acting. Profiles were never authentication; they are preferences. And the model was ultimately not corrected but monetised — additional paid "member" slots sell more access to the same ambiguity.

That is the durable lesson. A shared credential is not an identity, no downstream inference reconstructs one, and once the ambiguity earns money it stops being a defect anyone is funded to remove.

The regulatory consequence has already landed, and notably not for the sharing itself. In December 2024 the Dutch data protection authority fined the company €4.75 million — for inadequate information about how personal data was used, and for failing to answer subject access requests properly. The finding was, in effect, that the organisation could not adequately explain its own data practices when asked. That is the same root cause as the access model: a system that never recorded what it was doing cannot describe it afterwards.

This is also the exposure that widens as AI adoption increases. When published claims, privacy statements and actual system behaviour can be interrogated at scale — by regulators, by researchers, by any competent model reading your surfaces — the gap between what an organisation says it does and what it can prove it did stops being obscure. It becomes searchable.

The same applies directly to agents. An agent acting with a person's credentials rather than under its own bounded, revocable mandate is the household-password model rebuilt for software — and it will be equally irreversible, for the same commercial reasons.

3. The custody trade

Both directions are defensible; they optimize against different failures.

Participant-held (Nostr). The keypair is the identity. Maximum sovereignty: no platform can revoke you, no operator holds your secret. The structural cost is that losing the key loses the identity, and leaking it has no rotation story — rotating produces a new identity rather than a healed one.

Edge-held (here). Ed25519 keys are generated and used inside a Cloudflare Worker; private material stays in the platform keystore, and the public half is published at a JWKS endpoint anyone can verify against without an account. The platform attests; the world verifies.

What edge custody buys is rotation. A suspected compromise is a pointer flip: mint a new key, repoint the active identifier, and certificates issued afterward carry the new key while earlier ones remain verifiable against a published, retired key. A leak heals without a recall, and without anyone losing their identity.

The corresponding obligation is that keystore access is signing authority. That is why the perimeter matters as much as the curve: a root key held by the customer, separation of duties between who approves and who promotes, and a rotation ledger recording each ceremony by fingerprint. Trust is not the algorithm; it is the ceremony around the algorithm.

Side by side

Which key do you actually hold?

A reasonable question after all this curve talk: which one do I use? The short answer is that you never handle a signing key at all. Curves are internal machinery. What a human or a system holds is one of the credentials below, and only the first is issued to a person.

secp256k1 does not appear in this list, and that is the point of naming it: it is Nostr's curve, relevant here only as the comparison. In a participant-held model that key is your identity and its safekeeping is your problem. Here the equivalent responsibility is a single admin key you can rotate at will — and rotating it costs you a paste into a config field, not an identity.

So the practical answer to "what key do I use?" is: the admin key you mint yourself, once. Everything else is either issued automatically to a session, a job, or an agent, or handled inside infrastructure on your behalf.

Why the peer model was chosen, and where it ends

Buzz's key model is not arbitrary — it is the same primitive as peer-to-peer payment: self-custodied keys, direct settlement, no intermediary holding authority. Seen that way the choice is coherent, because a payment rail and an agent permission answer the same question: who may move what, under whose authority, settled how.

The divergence is the relationship being modelled. Self-custody is correct for a person acting on their own behalf, where the absence of an intervening party is precisely the point. An organisation delegating to an agent needs the opposite: authority that can be capped, scoped, expired and withdrawn by someone accountable for it. That is a principal-agent relationship, not a peer one — and a mandate is only meaningful if there is a party who can revoke it.

The same difference appears in payments the moment a rail crosses a border. Domestic card infrastructure, real-name requirements, settlement rules and merchant-of-record obligations are jurisdictional facts. A peer model is designed to make jurisdiction irrelevant, which is liberating for an individual and disqualifying for regulated commerce — the constraint does not disappear because the protocol declines to represent it.

4. Delivery under enterprise controls

Buzz ships as a desktop application for macOS, Windows, and Linux. For an open-source project with a developer audience that is a reasonable first surface: native performance, local key storage, an install anyone can inspect.

Inside a large organization an executable is a different kind of object. It enters through endpoint management, software approval, and an OS-by-OS support matrix — and the people who most need an audit trail (legal, compliance, finance, an external auditor) are precisely those who will never be issued a developer tool.

The harder blocker is the network shape. A Nostr client holds open connections to a set of relays: independently operated servers, chosen by the client, that receive and rebroadcast signed events. To a security team that is a decentralized egress path by design, and it lands on the questions their controls exist to answer:

• Which hosts does it connect to, and who operates them?
• What leaves the machine, and can data-loss prevention inspect it?
• Where do events come to rest, and in which jurisdiction?
• Can we demonstrate to a regulator where our record lives?

Self-hosting a private relay is possible and is the right answer for a serious deployment — but it converts an install into an infrastructure project, and until it is complete the default posture is workplace records replicating to third-party servers. Signed and tamper-evident: yes. Confined to approved infrastructure: no. Any organization with an egress policy, a data-residency clause, or a DLP mandate stops there, correctly.

The shape used here is the ordinary one those controls were written for: a browser talking to a named origin over HTTPS. One domain to allowlist, one tenancy holding the record, no persistent connections to unvetted servers. Public verification is a plain GET against a published key — an auditor checks a certificate without joining a network, installing anything, or being granted an account.

One build, three surfaces. The same Progressive Web App runs in the browser, installs to the desktop dock, and adds to a phone home screen — which is why rollout is a URL rather than a fleet deployment, and why a compliance reviewer can open it on the device already in their hand.

The install surface follows from the same choice. One Progressive Web App becomes the browser tab, the desktop application, and the phone home screen from a single build — so "roll this out" means sharing a URL rather than scheduling a fleet deployment, and updates ship when they are deployed rather than when the fleet next accepts a package.

A download also decides which devices exist. A desktop build reaches laptops; it does not reach the phone in a reviewer's hand, and adding that surface means a second build, a second store, and a second review cycle. This is not a hypothetical constraint — it is the exact problem early streaming products hit when a downloadable media player ran on PCs and could not reach iOS at all, and it was solved then the same way it is solved now: by moving to the browser and carrying entitlements, permissions, analytics and rights enforcement across intact. One Progressive Web App reaches laptop, desktop and phone from a single deployment, which is why "can a compliance officer open this on their phone during the meeting" has a different answer for each model.

A signed record nobody outside the engineering team can open is a record with an audience of one department.

5. Three legs, not one monolith

Holding keys at the edge does not create a single point of failure, because the stack is deliberately not one system. It is three planes that scale — and degrade — independently.

Independence is the point. When the record-keeping plane is slow, the edge still serves and buffers writes to replay. When the interface is being rebuilt, identity and entitlements are unaffected. When the edge deploys, nothing downstream is republished. A monolith converts any one of those events into an outage; three legs convert it into degraded capability in one plane while the others keep their footing.

Why these two vendors, specifically

The pairing is not incidental. Xano and Cloudflare formalised an integration partnership precisely because the split is a natural one: a managed backend that owns durable state and a global edge network that owns proximity and compute. Each is a category leader with an enterprise track record, published compliance posture, and a support contract someone can be held to — which matters more than elegance when a security review asks who is accountable at 3am.

The practical consequence is general availability through tools an organization already runs:

• No new protocol to approve. Everything speaks HTTPS and JSON over a named origin — the shape every existing gateway, proxy, SIEM, and DLP rule was written for.
• No new client to install. The interface is a URL. Endpoint management has nothing to package, and the auditor needs nothing but a browser.
• Standards, not inventions. RFC-defined signatures (EdDSA/JWS), RFC-defined key publication (JWKS), ordinary OAuth for provider identity. A reviewer can check our claims against specifications rather than against our documentation.
• Egress that resolves to two named vendors, both of which are almost certainly already on the organization's approved list and in its vendor register — rather than to a client-chosen set of relays that must each be assessed.
• Exportability. Because the system of record is a managed database rather than a proprietary format, "give us everything" is a query, not a support ticket.

Resilience follows from the same choice. The edge absorbs load and survives regional failure by design; the record plane is backed up, versioned, and restorable independently; the interface can be rebuilt without touching either. Three vendors' failure domains rarely coincide — and none of the three can unilaterally deny access to the evidence, because the verification key is public and the record is exportable.

Logging is passive to the locked data

The ledger records that something happened, to which record, under whose authority — without ever opening what is encrypted. Events are logged by reference and by hash: an entry names the subject, the capability, the timestamp, and the chain position, while the payload it refers to stays encrypted at rest. The log never needs the key to do its job.

That property is what makes the audit trail safe to distribute. Observability scales without widening the blast radius: hand an auditor the chain, or stream events to a warehouse, without handing anyone the contents.

6. Where this sits relative to a CRM

This is not a CRM replacement. It fills the layer neither a CRM nor an email platform was built to hold — the provenance layer beneath the data they already store.

Consider one field. A conventional platform records consent as a boolean: accepts marketing, true. That flag cannot say when it was granted, through which mechanism, under which version of the terms, or on which surface. Under GDPR, CPRA, and Consent Mode v2 the boolean is not the evidence — the provenance is. And when the record lives in a rented platform, the answer to "prove it" becomes "we exported a CSV."

A CRM is very good at being where the revenue team works. It is not designed to prove to a third party what an organization was permitted to do, and when. Different jobs — the provenance layer coexists with the CRM and feeds it, and if the relationship ends the evidence does not leave with the subscription.

7. The channel manager and PIM layer

The same distinction applies one layer up, where product data is managed and syndicated. Category incumbents — Salsify, Feedonomics, Productsup, Rithum among them — solve a genuinely hard problem: take a catalogue, normalize it, transform it per destination, and push it to dozens of marketplaces, retailers, and ad platforms at scale. Anyone who has hand-maintained a Walmart feed knows what that work is worth.

The architectural observation is not that these systems are deficient. It is that they are syndication-first, and syndication optimizes for a different question than compliance does.

A syndication system is designed to answer: what is the current value of this attribute, and has it reached every destination? Its data model is therefore a current-state record. Attributes are mutable fields; a price change overwrites a price; a market rule updates in place; a feed re-runs and the previous version has served its purpose. Throughput outward is the design goal, and by that measure these platforms perform well.

Regulation asks a retrospective question instead: what was true, when, in which market, and on whose authority?

• Price transparency (EU Omnibus) asks what the lowest price was during the 30 days before a reduction — a question about a series, not a current value.
• Consent and data residency ask whether a routing decision that placed data or an offer into a jurisdiction was covered by a consent state that existed at the time of the routing.
• Product security and conformity (CRA and adjacent regimes) ask which exact version of a claim, document, or bill of materials accompanied a specific release.

Nothing about a syndication platform prevents an organization from answering these. But the answer has to be reconstructed — from exports, feed logs, and whatever the destination retained — rather than read from a record that was designed to be evidence. Reconstruction is expensive, contestable, and gets weaker with time.

Two structural consequences are worth naming plainly, because both are architectural rather than anybody's fault:

Attribute collision has no arbiter. In a typical enterprise, product truth arrives from more than one upstream system — an ERP, a merchandising tool, a regional override, a spreadsheet an operator maintains. The syndication layer resolves conflicts by precedence rules and last-write-wins. That produces a working feed and destroys the audit question: when two systems asserted different values, which one was authoritative, at what moment, and who decided? Without a timestamped, signed record at the point of resolution, that question is unanswerable afterwards at any price.

Routing decisions are rarely bound to consent. Geographic and channel routing is configuration: this catalogue goes to these markets under these rules. The configuration is current-state, so the record of which rule was in force when a given offer reached a given market usually exists only as a changelog entry, if at all — and the consent state that should have governed it lives in a completely different system, on a different clock.

Complementary, not competitive

The conclusion is the same as with the CRM: keep the PIM. Syndication at scale is specialized work, and replacing it to gain provenance would be a poor trade.

What the provenance layer adds is the record the syndication layer was never designed to keep: a timestamped, hash-chained, signed entry each time a claim is published, a price changes, a routing rule applies, or a consent state governs a decision — verifiable afterwards by someone who does not trust either system. The PIM keeps answering what is the value now. The provenance layer answers what was true then, and who said so.

That division is why this integrates rather than displaces. Feeds continue to flow. The difference is that a year later, when a regulator, a retailer, or a claimant asks what your product asserted in a particular market on a particular date, the answer is a signed record rather than a reconstruction.

8. You do not have to build any of this

A fair objection to everything above: it reads like a cryptography project, and most teams do not have a cryptographer to spare. They don't need one. The primitives are already in the platforms, and the work is configuration rather than construction.

The token layer ships with the backend. Xano issues authentication tokens with custom claims as a standard feature — the auth/me pattern returns the caller's identity and whatever claims were bound at issue time. Those claims are the same place an entitlement, a scope, or a mandate reference lives. Encryption and signing are built-in functions, not libraries you vendor and maintain: you configure which claims a token carries and which endpoints require them. Nobody hand-rolls a cipher, and there is no key-handling code to get subtly wrong.

The edge layer is the runtime's own crypto. Signing and verification use the platform's native WebCrypto — generate a key, sign a payload, publish the public half. This is a handful of calls against a documented standard interface, not a bespoke implementation.

It reaches agents through MCP, not custom plumbing. Because authority already travels in the token's claims, exposing a capability to an AI agent over the Model Context Protocol is a matter of handing the agent a scoped token and letting the server resolve the claim on each call. The agent does not need to understand cryptography; it needs a token that is already bounded. The permission check happens server-side where it belongs — so an agent that misbehaves is refused rather than trusted to behave.

The skill required is reading a claim and deciding what it permits — ordinary application logic that any competent backend developer or technically-minded operator can implement. The heavy machinery (curve arithmetic, envelope encryption, chain construction) is already inside the platforms, maintained by their vendors and audited on their compliance schedule.

And you do not need a procurement cycle to start

It is worth being precise about the entry cost, because most enterprise architecture documents assume a platform commitment before the first line of work. That assumption does not hold here.

The function-orchestration stack is available on sign-up, free, in about five minutes — no organizational service level, no contract, no infrastructure request. What an individual gets is not a sandbox toy: it is the real orchestration runtime, with the same authentication, custom-claim, and function-stack primitives the paid tiers use. The service level buys support, scale, and organizational governance. It does not gate the capability.

The practical consequence is that an individual business analyst can build the whole thing — a working application and its trust framework — inside their own scope, on their own account, without asking anyone. Identity, claims, entitlements, the ledger, the endpoints an agent calls: all of it can exist and be demonstrated by one person before a single procurement conversation happens.

That inverts the usual adoption sequence. Instead of convince the organization → get budget → get infrastructure → build → discover what it actually needed to be, the order becomes:

1. Build it in individual scope — real, running, with real data flowing.
2. Prove the questions it answers — hand a reviewer a certificate they can verify against a public key, on their phone, without an account.
3. Hand off as documentation — the working system is transcribed into the organization's own artefacts: data SOPs, a functional specification in markdown, the schema and endpoint contracts that already exist because the thing was built rather than described.
4. Then buy the service level — for support, scale, and governance, against a system whose value has already been demonstrated rather than forecast.

This matters more than it sounds for the enterprise argument earlier in this document. The hardest part of introducing a provenance layer into a large organization is not technical and it is not cost — it is that the people who feel the compliance pain (a BA, an analyst, a compliance officer) are rarely the people who can commission infrastructure. A model where the person with the problem can build the answer themselves, and hand it over as a specification rather than a request, routes around the blockage entirely.

The infrastructure is not the differentiator

It is worth dispensing with a distraction. Modern platforms — self-hosted and managed alike — converge on the same commodity components: PostgreSQL for durable state, Redis for hot state and queues, containers for packaging, Kubernetes for orchestration. A self-hosted open-source workspace and a managed backend platform are, at the substrate, running the same well-understood pieces. Nobody wins this argument on infrastructure, and any vendor claiming a moat there is selling something else.

The difference is who operates and certifies it. Self-hosting means the organization runs that stack: patching, backup verification, key handling, access review, and the evidence that all of it happened — before an auditor will accept anything built on top. That is a real programme of work, and it is the part that quietly consumes the first two quarters of a self-hosted deployment.

A managed platform delivers the same primitives with that programme already done and independently attested. Xano's compliance posture includes SOC 2 certification, which changes the character of the conversation in two specific ways:

• The individual's build is already on certified infrastructure. What the analyst assembles in personal scope is not a prototype that must be rebuilt "properly" later — it is already sitting on the substrate the organization's own auditors will accept.
• The handoff is commercial, not architectural. Folding an individual account into an enterprise service level changes support, scale, governance, and contractual terms. It does not require re-platforming, re-implementing, or re-certifying what was built. The path from one analyst's afternoon to an organizational system is a contract, not a rewrite.

That is the practical reason this route survives contact with an enterprise. The usual failure of bottom-up adoption is that the thing which proved the point was built somewhere the organization cannot accept, so the reward for a successful demonstration is being told to start again. Here the demonstration and the production system are the same system.

That is the difference between a research posture and a deployment posture. A protocol that demands every participant manage their own keypair correctly places a cryptographic burden on people who did not sign up for one; a platform that binds authority into a token the backend already issues places it where it can be operated by a normal team — or, to begin with, by one determined analyst on a Tuesday afternoon.

9. Build your own

The choice on offer is usually presented as: adopt a workspace product, or adopt a decentralized one. For most enterprises both fail, for opposite reasons.

• A hosted team workspace. In practice this splits by organization type: agencies and smaller teams standardize on Slack, while most large enterprises mandate Microsoft Teams — it arrives inside an existing licence agreement, under identity and retention controls the organization already governs. Either way the outcome is the same for our purposes: the tool is approvable but it is another silo. Your record of who decided what lives in a vendor's tenancy, on their retention policy, exportable as messages. It answers where the conversation happened, never what was authorized. And notably, an enterprise that has already mandated Teams is not going to approve a second workspace product regardless of its cryptographic merits — the seat is taken.
• A decentralized client is architecturally interesting but rarely clears review: an executable on managed endpoints, persistent connections to relays nobody vetted, and key custody handed to individuals with no rotation path.

The third option is the one nobody pitches, because there is nothing to sell you: you already have the parts. A certified managed backend for identity, claims, and durable state. Edge compute for signing and verification. An interface layer you already publish. A warehouse you already load. That is the same substrate — Postgres, Redis, containers, orchestration — that the alternatives are built from, and in your case it is already through procurement.

What you assemble from those parts is the capability, not the product: participants and agents with real identity, actions that produce signed and timestamped records, an append-only history, and verification that needs no account. The workspace was never the point; the provable record of authority was.

Start where the value is already measurable

The fastest place to prove it is not an internal chat tool — it is the commercial edge, because the result shows up in revenue reporting rather than in an architecture review.

Channel → attributed event → BigQuery runs the whole pattern end to end today: a link or QR minted under your own key, every scan counted in a ledger you own, channel provenance carried into analytics and the warehouse, and the resulting order landing as an ordinary commerce order. Same identity plane, same signing, same audit properties as everything described above — pointed at a problem a growth team already has budget and urgency for.

Once that is running, the mechanism is proven inside your own organization, on your own infrastructure, with numbers a business owner recognizes. Extending it to agent mandates, firmware, or consent evidence is then a matter of scope rather than a new argument.

The permission wall this walks around

There is a specific reason this starting point works inside a large organization, and it is organizational rather than technical.

Building an audience the conventional way requires the advertising and analytics consoles: an audience builder, conversion configuration, a customer-match upload, a tag change. In most large enterprises that console access is centrally held — by a media team, a central marketing-operations function, or an agency of record — and it is not granted to the analyst or growth marketer who actually owns the campaign. This is a defensible control: those consoles hold spend authority and customer data, so access is restricted.

The consequence is that the person with the question cannot answer it. Requests queue behind a central team's roadmap. And because the work still has to happen, people route around the wall — a spreadsheet of identifiers here, a shared login there, an agency granted access "temporarily," a parallel tag deployed to get one campaign measured. That improvisation is where collision comes from: several partial systems asserting overlapping truth, none of them timestamped, none authoritative, and no record of who decided what.

This is also the most common bad assumption in an agency statement of work. Agencies work daily with clients where a marketer can open the analytics console and edit the event bus, so a delivery plan gets written on the premise that the client's BA or content team can do the same — configure a conversion, add a tag, adjust the data layer, upload an audience. In a large enterprise those are precisely the permissions that will not be granted, to anyone, on that timeline. The plan then stalls not on capability but on access, and the discovery usually happens after the contract is signed and the schedule is committed.

The same assumption produces the same stall on the workspace side: a plan that depends on the client installing a new desktop client — or joining a network outside the sanctioned one — will not survive review either, however good the software is. In both cases the mistake is identical: assuming that because a capability exists and the team is competent, the organization will permit it.

Planning against what an enterprise will actually approve is therefore not a limitation to work around; it is the design constraint. What survives is work that runs on infrastructure already procured, through permissions the team already holds, producing records the organization can verify without granting anyone new access.

Minting removes the dependency for the measurement half of the problem:

• The coupon and the tracking are created in the same act. A mint carries its own unlock code, so the offer and its attribution are one object rather than two tickets to two teams. No merchandising request, no separate campaign parameter convention to agree on.
• The signal reaches the warehouse through infrastructure that already exists. Scans stamp channel provenance into the visit, the existing analytics tag carries it, and the standard export lands it in BigQuery. No new console permission is required to produce this data, because it flows through the tag and export the organization already runs.
• The audience is built from the warehouse, not the console. Once the events are in BigQuery, segmentation and predictive modelling happen in the data platform — where analysts typically do have access — rather than in an advertising UI where they typically do not.

To be precise about the boundary: activating an audience into a paid channel still involves that channel's own permissions, and it should. What changes is that the analysis, the evidence, and the audience definition are built and owned before that conversation, in a system the analyst can reach — so the request that eventually goes to the media team is a specific, evidenced ask rather than a plea for access.

That is the same pattern as everything else in this document: the person who has the problem can produce the record themselves, and hand over something verifiable rather than a request to be trusted.

Open the Channel Wizard → — mint an attributed link or QR against a product, preview it free, and watch the first scan appear in the ledger.

10. The agency-to-enterprise handoff

Everything above meets its hardest practical test at a single moment: when an agency hands a system to the enterprise that will own it.

This is where most implementations quietly lose their history. The agency builds inside its own working context — its own accounts, its own credentials, its own chat tool — and delivers a system plus documentation written afterwards, from memory. The enterprise receives configuration without provenance. The questions that surface six months later are the ones nobody can answer:

• Who set this value, and on whose authority?
• Was this data flow reviewed, and against which consent terms in force at the time?
• Which decisions were the client's and which were the agency's?
• What exactly was true on the day of handover, before we started changing things?

The usual remedy is a document written at the end — a specification describing what the system is, produced separately from the system itself, accurate on the day it is signed and drifting from that moment on. Credentials get rotated, access is revoked, and the institutional memory leaves with the people.

A provenance layer changes the shape of the handoff, because the record is produced as work happens rather than reconstructed afterwards. Three properties do the work:

• The agency operates under scoped, attenuated grants from day one. It holds exactly the capabilities it needs, within its own scope, unable to grant itself more (see the delegation rules earlier). It is a collaborator by construction, not by policy — which also means it never holds the credentials that would have to be rotated in a panic later.
• Every consequential action is already attributed. Configuration changes, key ceremonies, consent decisions, and publishing events land in the ledger under the identity that caused them, timestamped, as they happen. Nobody has to remember; the record already exists.
• Handover becomes revocation, not reconstruction. Ending the engagement means revoking the agency's grants. The system continues, the history remains intact and verifiable, and the enterprise inherits a record it can audit rather than a document it has to trust.

The specification then plays its proper role. Rather than being the primary evidence, it becomes the readable summary of a system that can prove its own state — data SOPs and a functional specification that describe a thing the organization can independently verify. That is the same movement described earlier for the individual analyst, one scale up: build it in a scope you control, hand it over as documentation plus a verifiable record, and let the receiving organization confirm rather than believe.

This is also why the workspace question is a distraction. The agency will be on Slack and the enterprise on Teams; the boundary between them is real and will not be dissolved by adopting a third tool. What crosses the boundary intact is not conversation — it is the signed record of what was authorized, which is legible on both sides and belongs to neither.

The compounding cost: churn

The expensive version of this problem is not a single messy handover. It is what happens when an inherited system has no record and then people keep leaving.

Whoever inherits an undocumented implementation spends their first months on archaeology: reading configuration to infer intent, testing in production to discover behaviour, and interviewing colleagues about decisions made by people who have since moved on. That work produces no new capability. It is pure re-derivation of knowledge the organization already paid for once.

Then it compounds. Every departure — an agency rotating staff, a contract ending, an internal reorganization — removes context that was never written down, so the next team re-derives it again, slightly differently. Configuration drifts from documentation, documentation drifts from intent, and eventually the safest-looking option is to rebuild rather than to understand. That is how a working system becomes a replacement project, and why the true cost of a bad handover is usually recognized two teams later, by people with no idea they are paying it.

The most damaging losses are not technical details but reasons. Any competent engineer can read a value out of a configuration file. Nobody can read why it was set — which market rule required it, which review approved it, which consent terms were in force when it was decided. Absent that, decisions get remade in good faith and wrongly, because the constraint that produced the original is invisible.

A record produced as work happens changes the economics on both sides of the relationship. Onboarding reads the ledger rather than interviewing people who have left. The receiving organization can see what was authorized and when, without trusting anyone's recollection. And the agency benefits at least as much: a demonstrable handover ends an engagement cleanly instead of leaving an obligation that resurfaces every time something breaks, and an inherited project that can explain itself is a project that can be quoted accurately rather than absorbed at a loss.

Who actually pays for a missing record

It is worth being explicit about something the cost analysis above leaves out, because it is the part that matters most to the people doing the work.

When a system built on undocumented decisions eventually fails, it fails architecturally — a constraint nobody wrote down, a permission model that could not answer the question, an integration whose migration was somebody else's schedule. But the person standing closest to the failure is almost never the person who designed it. It is whoever inherited it: the analyst, the operator, the internal owner who arrived after the decisions were made and was expected to keep it running.

Without a record, there is nothing to distinguish a failure that was inherited from one that was caused. No evidence that the constraint predated the person, that the risk was raised and the remediation declined, that the change which would have prevented it was outside their authority to make. The absence of the record does not merely make the organization slower to recover. It transfers the blame to the individual least able to have prevented it, and does so silently — because the thing that would have exonerated them was never written.

So a provenance layer is not only an institutional control. It protects the operator. A signed, timestamped account of what was authorized, by whom, under which constraints, and what was flagged and by whom, is the same artifact that answers a regulator and the one that answers "was this reasonable, given what they were handed." Systems that record their own history are fairer to the people who inherit them — and the people who inherit them are, disproportionately, the ones carrying institutional knowledge that no document captured.

11. The same discipline, applied to the interface

It would be inconsistent to argue for provable records in the data plane and then build the interface on conventions nobody can verify. The presentation layer decays the same way an undocumented integration does, and for the same reason: it encodes decisions without preserving the reasoning behind them.

The common failure is a utility-class system applied without a system behind it. Markup accumulates strings like text-sm text-gray-500 mt-2 at every call site, and six months later nobody can distinguish a deliberate hierarchy decision from a guess someone made on a Tuesday. The next person cannot safely reuse the intent — because the intent was never expressed — so they add a variant. Then another. The result is drift with a build step: a codebase where every surface is slightly different and no one can say which version is correct.

That is the same knowledge-loss pattern as the handover problem, one layer up. The values survive; the reasons do not.

The discipline that holds is not a preference for any particular framework. It is four commitments:

• One compiled first-party stylesheet, namespaced. A single source shared across every surface — marketing site, storefront, embedded components — with namespacing that makes collision structurally impossible rather than merely unlikely. Surfaces cannot fight each other over specificity if they cannot address each other's rules.
• An existing component vocabulary rather than a private dialect. Adopting a documented system (BEM-namespaced components, for instance) means the contract is written down by someone else and does not evaporate when the person who invented it moves on. A private class taxonomy is institutional knowledge with no custodian.
• Semantic tokens with literal fallbacks. Values referenced as var(--token, literal) degrade to something correct when a token is missing, instead of degrading to nothing. This is the same fail-safe posture the data plane takes: a missing input produces a defined state, not an undefined one.
• Constraints stated as rules, not taste. "The lightest permissible grey for text is a specific value meeting AA contrast." "No grid may leave a widowed item." "Emphasis is carried by weight, not hue." Each is checkable, which is what separates a standard from an aesthetic.

The last commitment is the one that actually holds: enforce the rules in the test suite. A rule in a style guide is a preference someone will forget under deadline. A rule in the harness is a property of the system. Contrast floors, load order, and token usage can all be asserted statically — and when they are, the constraint survives every future contributor without anyone needing to remember it. In this codebase, adding exactly such a check found real violations on its first run, which is the ordinary outcome: the rules you believe you are following are not the rules you are following until something verifies it.

The through-line with everything above is not an analogy. It is the same principle: write the constraint somewhere that enforces itself, so the knowledge outlives the people who hold it. A hash-chained ledger does that for authority. A failing test does it for design. Precision is not fussiness in either case — it is the property that makes a system inheritable.

Why this now matters at inference scale

There is a newer reason to hold this line, and it is not aesthetic.

Content is increasingly rendered, translated, localized, summarized, and answered by language models rather than read only by people. That changes the economics of imprecision. A single canonical piece of source text now scales globally through inference: one product description becomes market variants, answer-engine responses, agent-facing summaries, and localized surfaces — automatically, at volume, without a human in each path.

Which means the discipline of the source text is the discipline of every derived output. Ambiguity does not stay put; it propagates and amplifies. A vague claim becomes a differently-vague claim in nine languages. A value stated without its unit, market, or effective date becomes an assertion no downstream reader — human or model — can qualify. The cost of sloppiness used to be one confusing paragraph; now it is a fan-out.

The same properties that make a system inheritable make content safely inferable:

• One canonical source, not many copies. Derived surfaces reference it rather than duplicating it, so a correction propagates instead of leaving stale variants behind — the content equivalent of a single system of record.
• Structure that carries meaning, not just formatting. Identifiers, effective dates, market scope, and units expressed as data rather than implied by prose. A model can qualify a claim it can see the qualifiers for; it will guess at one it cannot.
• Auditable edit history with attribution. When both humans and AI co-author, the useful question is not "who typed this" but "what changed, when, on whose authority, and against which source." That is the ledger property applied to text — and it is what makes AI-assisted authorship reviewable rather than merely fast.
• Constraints that hold at the boundary. The same reason a contrast floor belongs in the test suite: a generated surface should fail a check rather than ship a claim nobody licensed it to make.

Co-authorship between people and models works when the source is precise enough to be trusted and instrumented enough to be reviewed. Both authors then operate on the same artefact, with the same constraints, and every edit leaves a trace either can inspect. That is not a workflow preference — at inference scale it is the difference between content that can be corrected once and content that has to be chased across every surface it reached.

12. What this means operationally

• Identity you can retire. Personnel change, agents are deprecated, contractors roll off. Rotation and revocation are routine operations, not identity funerals.
• Separation of duties enforced in the data plane. Whoever authors a change cannot promote it; whoever signs off cannot deploy it. Governance is a gate, not a job title.
• Delegation that cannot amplify. A holder grants only capabilities they themselves hold, within their own scope, to a bounded depth — the tree cannot sprout new roots.
• Evidence an outsider can check. Certificates verify against a published key with no account and no trust in the platform.
• Consent bound to the record. The consent state at the moment of the grant is signed into the certificate.

13. Glossary of terms

Written for readers who know cryptography but not this stack, and for readers who know neither. No term below is proprietary — where a name is ours, it is marked.

Nostr — "Notes and Other Stuff Transmitted by Relays." A minimal open protocol in which identity is a secp256k1 keypair and every message is a signed JSON event. There is no canonical server: clients publish events to, and read them from, a set of independently operated relays. Authorization is deliberately out of scope — the protocol proves authorship, not permission.

Relay — a WebSocket server that accepts signed events and rebroadcasts them to subscribed clients. Relays are chosen by the client, may be public or private, and hold no authority over identity; they are transport and storage, not gatekeepers.

secp256k1 / Ed25519 — two elliptic curves used for digital signatures. secp256k1 (Schnorr signatures in Nostr, also Bitcoin's curve) and Ed25519 (EdDSA, RFC 8032) are both modern and fast; the security-relevant difference here is not the curve but who holds the private key and whether it can be rotated.

Key custody — the question of which party physically holds private key material. Participant-held means the end user or agent holds it; edge-held (ours) means it lives in the platform keystore and is used inside a compute isolate at the network edge. Custody determines what recovery and rotation are even possible.

Key rotation — replacing a signing key while preserving the identity that signs. Requires an indirection between "who this is" and "which key is currently active." Where the key is the identity (Nostr), rotation in this sense does not exist: a new key is a new identity.

JWKS — JSON Web Key Set (RFC 7517): a public endpoint, conventionally /.well-known/jwks.json, publishing the public halves of signing keys with a key id (kid). A verifier fetches it and checks any certificate offline afterward — no account, no API key, no trust in the issuer's honesty.

Entitlement — (our term) a scoped, revocable grant recording what a subject may do: a set of capabilities plus scope qualifiers (brand, market, channel, shop) and a state. Resolved server-side on every call, never trusted from the client.

Capability — a single named permission inside an entitlement (for example firmware.publish). Capability-based security grants authority to do a specific thing, as opposed to role-based access control, which grants authority to be a kind of person.

Mandate — (our term, aligned with the AP2 agent-payments pattern) a signed grant under which an agent acts on a person's behalf, carrying a spend cap, a scope, and an expiry, and revocable at any time. The agent never holds the principal's credentials; it holds a bounded, verifiable permission to act.

Attenuated delegation — the rule that a grantor may only pass on capabilities they themselves literally hold, within their own scope, to a bounded chain depth, and may never grant the right to grant. It makes privilege escalation structurally impossible rather than merely forbidden.

Separation of duties (SoD) — an integrity control in which no single actor completes a sensitive operation alone: whoever authors a change cannot promote it, and whoever signs it off cannot deploy it. Enforced here as distinct capabilities in the data plane, not as job titles in a policy document.

Hash-chained ledger — an append-only log in which each row's hash includes the hash of the row before it. History cannot be quietly edited, only visibly broken — a tamper-evident structure, not a tamper-proof one.

Chain of custody — the documented, unbroken sequence of who held or acted on a record, when, and under what authority, from creation to the present. The term comes from evidence handling: a fact is only admissible if every transfer between hands is accounted for. Applied to data, it is the difference between having a record and being able to prove where it has been. Here it is assembled from three parts working together — the hash-chained ledger (order cannot be altered), the signed certificate at each grant (authority at that moment is attested), and consent binding (the terms in force are captured, not reconstructed later). A CSV export has no chain of custody; a signed chain does, and it survives the vendor relationship that produced it.

Custody has two distinct meanings that this document keeps apart, and confusing them is the most common source of muddle in these debates:

**Custody of the key** — who physically holds the private key material that produces signatures. Two models:

• Participant custody — the key lives with the end user or agent, typically on their device. Strength: no operator can sign as you, revoke you, or be compelled to hand over your secret; sovereignty is absolute. Cost: the key is the identity, so loss is permanent and leakage is unrecoverable — there is no rotation, only replacement with a new identity. Recovery and helpdesk support are structurally impossible; an employee who leaves with a key leaves with the identity.
• Edge custody — the key lives in a platform keystore and is used inside a compute isolate at the network edge, never leaving it. Strength: the identity is an indirection, so a key can be rotated, retired, or revoked while the identity persists; a compromise is healed rather than mourned, and normal operations (offboarding, incident response, an auditor's request) are possible. Cost: keystore access is signing authority, so the operational perimeter around it — customer-held root, separation of duties, a fingerprint-level rotation ledger — becomes load-bearing and must itself be evidenced.

**Custody of the record** — who holds the data whose history you are proving. Participant-held keys do not imply participant-held records: in a relay model the events replicate to servers chosen by the client, so the key stays with the person while the record spreads to third parties. In the edge model the inverse holds: the key is centrally held while the record sits in one accountable tenancy you can name, export, and locate in a jurisdiction.

Chain of custody is only as strong as the weaker of the two. A perfectly sovereign key attesting records scattered across unvetted relays cannot answer "where does our data live"; a perfectly located record signed by a key nobody can rotate cannot answer "what happens when that key leaks." The pairing chosen here — edge-held key, single accountable record plane, publicly verifiable output — is the combination that answers both questions in a form an auditor accepts.

JWT / JWS / JWE — three layers of the JSON Web Token family, routinely conflated:

• JWS (Signed) — a payload plus a signature. Anyone can read it; nobody can alter it undetected. Our licence, attestation, and mandate certificates are JWS with EdDSA — deliberately readable, because the point is public verifiability.
• JWE (Encrypted) — a payload sealed so only a holder of the decryption key can read it. Used where the contents are sensitive rather than merely authentic: the identity plane's PII and payment-adjacent claims travel as JWE, so an intercepted token yields ciphertext rather than a person.
• JWT — the umbrella term, and the source of the confusion: a "JWT" may be signed, encrypted, or nested (a JWS wrapped inside a JWE, giving both authenticity and confidentiality). "We use JWTs" says almost nothing on its own; which of the three you mean is the security-relevant fact.

The division of labour matters: sign what must be provable, encrypt what must be private, and never rely on one to do the other's job. A signed-only token protecting personal data leaks it to anyone who intercepts it; an encrypted-only token proves nothing to a third party who cannot decrypt it.

Consent binding — signing the state of a subject's consent (version, purposes, timestamp) into the certificate issued at the moment of a grant, so a later dispute reads the terms exactly as they stood rather than as they were subsequently edited.

Provenance — the recorded origin and history of a data point: not just that consent is true, but when it was given, by which mechanism, under which terms version, and on which surface. Regulators increasingly treat the provenance, not the flag, as the evidence.

Egress path — the route by which data leaves a managed device or network. Security teams control egress with allowlists, inspection, and residency rules; software that opens connections to hosts the organization has not vetted is an egress-policy problem regardless of how well the payload is signed.

DLP (Data Loss Prevention) — controls that inspect outbound traffic for regulated or confidential content. DLP requires inspectable, enumerable destinations, which is why "connects to a client-chosen set of third-party servers" is a difficult posture to approve.

PWA (Progressive Web App) — a web application that installs from the browser to a desktop dock or phone home screen from a single build, updates itself on deploy, and works offline via a service worker. It requires no app-store review and no per-platform binary, so it clears endpoint-management review as a URL rather than as software.

System of record — the authoritative store for a class of data, against which all copies are reconciled. Here, identity, consent, entitlements, and the ledger; caches and projections elsewhere are explicitly not authoritative.

Attestation — a signed statement that some fact was true at a point in time (this image was vaulted, this license was granted, this deletion completed). Its value is that it can be checked long afterward by someone who does not trust, and need not contact, the issuer.

14. This is the data trail regulators are asking for

Everything described here — the signed grant, the timestamped access record, the hash-chained history, the verifiable certificate — can read as engineering preference. It is not. It is close to a description of what recent EU regulation expects an organization to be able to produce.

Consider what each regime actually asks for, stripped of legal language:

• The Cyber Resilience Act (Regulation (EU) 2024/2847) expects manufacturers of products with digital elements to maintain a software bill of materials, ship security updates over a defined support period, and report actively exploited vulnerabilities against a clock — an early warning, a fuller notification, and a final report. Reporting an exploitation means answering who obtained this build, when, and in which versions — which is an access record, not a document. Reporting obligations begin 11 September 2026; the fuller obligations apply from 11 December 2027.
• Price transparency (the Omnibus Directive, 2019/2161) expects a seller to substantiate the prior lowest price over the preceding 30 days — a series of price states with timestamps, not a current value.
• Consent under GDPR, and Consent Mode signalling, expect an organization to show not merely that consent exists but when it was given, by what mechanism, under which version of terms, and for what purpose — provenance, not a flag.

Set side by side, these ask for the same three properties: an identifier that resolves, a record with a timestamp and an author, and independent verifiability. That is not a coincidence of drafting. It is what "prove it" means when the party asking was not present at the time and does not trust you by default.

Which is why the firmware-and-SBOM case is the clearest illustration rather than a niche feature. A vaulted firmware image produces exactly this trail as a by-product of ordinary distribution: the image encrypted at rest, an Ed25519 certificate binding product, version, digest and SBOM at the moment of upload, a hash-chained ledger of every grant, denial and served byte-stream, and public verification against a published key. Nobody assembles that afterwards for an auditor — it exists because the distribution mechanism produced it.

The general lesson holds beyond firmware: if a regime can ask you to prove a past state, the only cheap answer is a system that was already recording. Reconstruction from exports and memory is expensive, contestable, and gets weaker precisely as the question gets older. See Firmware, SBOM & the Cyber Resilience Act for the mapping in detail, including the framework table — offered as engineering guidance, with jurisdictional sign-off a matter for counsel.

15. Verify it yourself

Licenses as the buyer sees them: each granted capability with the date it was granted, its terms, and three forms of proof — a durable receipt, a verification link checked against the public key, and a QR an auditor can scan from a printed page.

Every capability a buyer holds appears in their own account with its proof attached — a receipt, a verification link, and a QR an auditor can scan from a printed page. That is the difference between being told your access is recorded and being handed the record.

Nothing above is self-attested. The public key set is served at /.well-known/jwks.json; any certificate issued by this platform — a license grant, a firmware upload attestation, a data-deletion completion record — can be checked against it at /license/verify with no account and no trust in us.

16. Where this is implemented

Everything described above is running software, not a proposal. Each product below is one capability of the same plane — the same entitlements, the same signing keys, the same ledger.

Read the middle column first if you are the person who has to justify this internally. Nothing here introduces a new vendor category: the work happens inside Shopify, Cloudflare, Xano, Webflow, Google Analytics, and BigQuery — platforms that are, in most organizations, already through procurement, already in the vendor register, and already covered by an existing DPA. What is being bought is configuration of tools you have, not another tool to assess.

The full catalogue lives at crm-sync.dev/pages/products, and the knowledge base — including this document — at crm-sync.dev/pages/knowledge-base.

What a procurement review actually has to clear

• No new client software. Nothing to package, sign, or deploy to managed devices; the surface is a URL that existing web policy already governs.
• No new egress destinations of consequence. Traffic resolves to vendors already on the approved list, over ordinary HTTPS, inspectable by existing controls.
• No new data-residency question beyond ones already answered for the underlying platforms, because the system of record is your own tenancy.
• No proprietary verification tooling. Auditors verify with a GET and a published key — no licence, no account, no NDA.
• No lock-in on the evidence. The record is exportable and the verification key is public, so the proof outlives the commercial relationship.

Buzz is a product of Block, Inc. This comparison reflects its public launch documentation as of 27 July 2026 and is offered as architectural analysis, not as a claim about its roadmap. Both models are legitimate engineering positions; they optimize against different failure modes, and the right choice depends on whether sovereignty or recoverability is the constraint that binds.