Running AI agents on KXCO: the guide to verifiable, post-quantum agents

01Why AI agents need a new kind of infrastructure

Start with the failure mode, because it is the whole argument. A human operator has a superpower an agent does not: judgment under ambiguity, backed by the ability to fall back on discretion. When a wire looks off, a person calls the counterparty. When a document seems forged, a lawyer asks for the original. When a login is suspicious, a fraud team pauses it. That fallback is the invisible substrate the entire digital economy quietly runs on. It is slow and expensive, and it works precisely because a human can improvise when the data is incomplete.

An agent has none of that. It cannot "get a feel" for a counterparty. It cannot phone a bank. It has to make a decision from the data in front of it, and it has to do so at a volume and cadence that makes human review impossible after the fact. So the data in front of it must be self-describing and self-proving: structured enough for a machine to parse, verifiable enough that the machine can check it without asking anyone, and universal enough that every other system computes the same answer. Absent that, an agentic economy is just the old fragmented mess running faster — and failing faster, with no one in the loop to catch it.

This is why "put an LLM behind an API key" is not agent infrastructure. It is a chatbot with a credit card. The moment an agent can move value, sign a contract, or act for someone else, three specific problems become load-bearing:

• Authentication that cannot be replayed. A bearer token or API key is a shared secret. Anyone who observes it — in a log, in transit, in a compromised dependency — can act as the agent. For a component that transacts autonomously, a replayable credential is not a risk to be managed; it is a breach waiting for a timestamp.
• Authorisation that is scoped and provable. "This agent is allowed to do things" is not authorisation. "This agent may move up to this amount, for this owner, to this class of counterparty, in this jurisdiction, until this date" is — and it has to be checkable by the party on the other side, not just asserted by the agent.
• Accountability that outlives the moment. When an agent acts, someone will later need to prove what it did, who authorised it, and that the record has not been altered — possibly years later, possibly in a dispute, possibly against an adversary with far more compute than exists today.

A human can call the bank to confirm a signature. An agent cannot. It needs cryptographic proof — the way a network needs a protocol before it can carry traffic.

The attack surface changes shape when the human leaves

It is worth being precise about why a token-based design that was fine for a human-driven app becomes dangerous for an agent, because the intuition "it worked before" is exactly what gets teams into trouble. With a human in the loop, a stolen session token has a natural circuit-breaker: the human is only active for minutes at a time, notices anomalies, and re-authenticates through channels an attacker rarely controls end-to-end. An agent has none of those brakes. It runs continuously, it holds credentials for as long as it lives, and it will act on a forged instruction with the same diligence it applies to a genuine one. The window between "credential compromised" and "damage done" collapses from a human reaction time to a machine one.

Two failure modes dominate in practice. The first is credential exfiltration: a shared secret leaks through a log, a misconfigured environment variable, a compromised dependency, or a captured request, and the attacker replays it. The second, newer and specific to agents, is instruction injection: the agent is manipulated — through its inputs, its retrieved context, or a poisoned tool response — into choosing to take a harmful action it is fully authorised to take. Per-action signing and scoped authority do not magically solve injection, but they change what it can achieve: a signed action is attributable and non-repudiable, and scoped authority caps the blast radius of any single manipulated decision. The design assumption is not "the agent will never be fooled" — it is "when it is fooled, the damage is bounded, attributable, and provable after the fact."

And then there is the deadline that makes all of this urgent rather than merely tidy. The cryptography that underwrites every authentication above — RSA, ECDSA — has a published expiry. A large enough quantum computer breaks it outright, and "harvest now, decrypt later" means the exposure is already live: an agent signing an agreement today with classical cryptography is signing something that becomes forgeable within the lifetime of the agreement. Just as machines are about to generate an explosion of consequential, autonomous actions, the cryptographic floor those actions stand on is scheduled to give way. The only sane response is to lay a post-quantum, verifiable floor first — before the volume of machine actions makes retrofitting impossible. That floor is what this guide teaches you to build on.

02The four things every agent action must satisfy

KXCO's design rests on a single rule that turns out to be exactly the rule an agent needs: nothing is real until trust, judgment, record and permission all hold at once. These are not four products to buy; they are four properties every consequential action must have, and the platform makes each one concrete.

• Trust — the mathematics that makes an action unforgeable, and keeps it unforgeable against a quantum adversary. Post-quantum signatures (ML-DSA-65) and encryption (ML-KEM-768), standardised by NIST as FIPS 203/204/205.
• Judgment — the intelligence that screens, scores and interprets. For agents, this is both the agent's own reasoning and the platform's screening of the agent's actions against a verifiable model of the world.
• Record — the shared, tamper-evident memory anyone can check without a referee. This is Armature L1.
• Permission — what is allowed, by whom, where, and until when. Scoped authority, checked live at the moment of action, not assumed at build time.

Watch how naturally an agent maps onto this. An agent's identity and delegated authority are Trust and Permission. Its signed intent is Trust. The screening of that intent is Judgment. Its settlement is Record. And the later verification by a counterparty is Trust again — exercised by someone else, with no need to trust the agent or KXCO. The diagram below is the whole model in one image; every section that follows makes one edge of it real in code.

The interactive graph further down (section 12) lets you trace the same relationships node by node on the live rendering engine we use across the platform. For now, hold onto the shape: an agent is a node in a graph of identities, keys, authorities, actions and records — and the point of the infrastructure is that every edge in that graph is provable.

03Give your agent an identity

An identity, on KXCO, is not a row in our database that you have to trust us about. It is a keypair the agent controls, whose public half is published and whose private half never leaves the agent. Issuing one is the first thing you do, and it is deliberately boring: generate a post-quantum keypair, keep the secret key inside the agent, register only the public key.

# 1 · generate a post-quantum keypair for the agent (ML-DSA-65 / FIPS 204)
npx kxco-pq keygen --algo ml-dsa-65 --out ./agent-identity

# produces two files:
#   agent-identity.key  → the SECRET key. Never leaves the agent's runtime.
#   agent-identity.pub  → the PUBLIC key. Safe to publish and register.

In code, the same thing, so you can mint an identity at first boot and persist the secret to the runtime's own protected storage:

// issue an agent identity at first boot
import { keygen } from 'kxco-post-quantum'

const { publicKey, secretKey } = keygen({ algorithm: 'ml-dsa-65' })

// secretKey stays in the agent runtime (see §09 on hosting & key custody)
await vault.put('agent/mldsa/secret', secretKey)

// register ONLY the public key + a human-readable label with KXCO Verified
await fetch('https://verify.kxco.ai/api/identities', {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({
    subjectType: 'agent',          // same API for people, orgs and agents
    label: 'procurement-agent-01',
    algorithm: 'ml-dsa-65',
    publicKey                        // the ONLY secret-adjacent thing we store is not secret
  })
})

Three properties of this are worth dwelling on, because they are what make an agent identity usable where an API key is not.

The same API issues identities for people, organisations and agents. An agent is not a second-class citizen bolted onto a human-centric identity system; it is the same kind of subject. This is what lets an agent's authority be expressed as a first-class relationship — owner —[:DELEGATES]→ authority —[:SCOPES]→ agent — rather than as a flag on a service account. The identity model is the graph shown below.

KXCO stores public keys, not secrets. There is no honeypot of agent credentials to steal, because the thing that would let you impersonate an agent — its secret key — is never in our custody. This inverts the usual breach calculus: compromising KXCO's identity store gives an attacker a list of public keys, which are, by design, public.

Verification needs no account and no KXCO server. Because an identity is "this public key, with this label, attested at this time," a counterparty checking an agent's action needs only the public key and the open-source verifier. They do not call an API, they do not authenticate to us, and their check keeps working if we do not. That is the difference between an identity and a login.

Rotation, revocation and recovery

Long-lived autonomous components need a key lifecycle, and the design goal is that no part of it ever moves a secret. Because KXCO stores only public keys, all three operations are public-key operations:

• Rotation — the agent generates a fresh keypair in its runtime, registers the new public key against the same identity label, and marks the previous key superseded. Actions signed before the rotation remain verifiable against the old public key (which is never deleted, only retired), so history does not break; new actions use the new key. Rotate on a schedule, and immediately on any suspicion of runtime compromise.
• Revocation — retiring a key with an effective timestamp lets a verifier reason correctly about time: a signature is valid if the key was live when the action was signed and anchored, even if the key is later revoked. This is why anchoring the action's timestamp (§05) matters — it lets "was this key valid then?" be answered without trusting anyone's clock after the fact.
• Recovery — an agent that loses its key is not a lost account; it is a new keypair registered under the owner's authority. The owner's delegation is the durable thing, not any individual agent key. This is a deliberate inversion of the human model, where the credential is the identity; for an agent, the delegation edge from the owner is the identity, and keys are replaceable leaves.

The practical upshot is that key management for a fleet of agents becomes an operation you can automate and audit rather than a fragile secret-shuffling exercise. A compromised agent is contained by revoking one key and rotating one runtime — not by rotating a shared secret that a dozen services read.

Credentials: attaching claims to an agent

An identity says "this key is this agent." Often you also need to say something about the agent: which owner it belongs to, what class of task it is certified for, that it passed a particular review. These are credentials — signed claims bound to the agent's identity — and they compose with the identity rather than replacing it. A credential is issued by some authority (the owner, an institution, KXCO Verified), signed, and presented by the agent alongside its action. The verifier checks two things: that the action is signed by the agent's key, and that the credential is signed by an authority it trusts and genuinely refers to this agent. Because credentials are just more signed claims over public keys, they are checkable with the same tooling and carry the same no-lock-in property — a counterparty verifies "this agent, certified by this institution, for this class of action" without calling anyone.

04Sign every action — no bearer tokens

Here is the single most important behavioural change when you move an agent onto KXCO: the agent stops sending a token that says "trust me" and starts sending a signature that proves it. Every request the agent makes carries an ML-DSA-65 signature over the exact bytes of that request. The receiver verifies the signature against the agent's published public key. Nothing replayable ever crosses the wire.

// sign an outbound action with the agent's own key
import { sign } from 'kxco-post-quantum'

const action = {
  intent: 'transfer',
  from: 'agent:procurement-agent-01',
  to: 'merchant:supplier-42',
  amount: 1250.00,
  currency: 'USD',
  nonce: crypto.randomUUID(),        // anti-replay
  ts: Date.now()
}

const payload = new TextEncoder().encode(JSON.stringify(action))
const signature = sign(payload, agentSecretKey)   // ML-DSA-65 signature

// attach the signature + key id; send the ACTION, not a secret
await fetch(endpoint, {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    'x-kxco-key-id': 'procurement-agent-01',
    'x-kxco-signature': signature
  },
  body: JSON.stringify(action)
})

On the receiving side — whether that is your own service, a counterparty's, or a KXCO product — verification is a single call, and it requires nothing from KXCO:

// verify an inbound agent action — no KXCO server involved
import { verify } from 'kxco-verify'

const ok = verify({
  payload,                // the exact bytes that were signed
  signature,              // from x-kxco-signature
  publicKey,              // the agent's published public key
  algorithm: 'ml-dsa-65'
})

if (!ok) throw new Error('unforgeable check failed — reject')
// ok === true proves: THIS agent authorised THESE EXACT bytes,
// and nothing has been altered since. Non-repudiable and quantum-safe.

The webhook adapters make this drop-in for the common frameworks, so an agent's outbound events are signed and its inbound events are verified without hand-rolling the middleware:

// verify signed agent webhooks in Express / Fastify / Hono / Workers / Vercel
import { verifyWebhook } from 'kxco-post-quantum-webhook'

app.post('/agent/callback', verifyWebhook({ registry: myAgentKeyRegistry }), (req, res) => {
  // req.kxco.verified === true — the body is proven, act on it
  res.json({ received: true })
})

Why this beats the token even before you care about quantum

It is tempting to file "post-quantum" as the reason to do this, but per-action signing wins on classical grounds first:

• No replay. The signature covers a nonce and timestamp inside the payload, so a captured request cannot be resubmitted. A stolen bearer token, by contrast, is valid until it expires or is revoked — a window an autonomous system cannot afford.
• No shared-secret storage. The receiver stores a public key. There is no credential on the server that, if leaked, lets someone act as the agent.
• Non-repudiation. "The agent did X" is not a log line you have to trust; it is a signature only the agent's key could have produced, over the exact bytes of X. In a dispute, that is the difference between evidence and hearsay.
• Portable proof. The verification is the same for your service, a regulator, and a counterparty who has never heard of you. Trust is established once and checked freely thereafter.

Then quantum makes it non-optional: the signature is ML-DSA-65, so the proof it produces is still a proof in 2035, when a classical signature from 2026 may be forgeable. For an agent that signs agreements meant to hold for years, that is not a nice-to-have — it is the requirement.

Canonicalization, nonces and clock skew — the sharp edges

Signing is simple; signing correctly has three edges that bite teams new to it, and an agent that gets them wrong will produce signatures that fail to verify intermittently — the worst kind of bug. Name them up front:

• Canonicalization. A signature is over exact bytes, and JSON.stringify does not guarantee stable key ordering or whitespace across languages and versions. If the signer serialises {a:1,b:2} and the verifier reconstructs {b:2,a:1}, the bytes differ and the check fails though nothing was tampered with. Fix it by signing a canonical encoding — sort keys, fix the encoding, or sign a hash of a canonical form — and by having the verifier check the bytes it received rather than a re-serialised object. When in doubt, sign the raw request body and verify that same body.
• Nonces. The nonce is what makes a captured request un-replayable, but only if the verifier actually enforces uniqueness. Keep a short-lived record of seen nonces (a cache with a TTL matched to your accepted clock-skew window) and reject duplicates. A nonce you generate but never check is decoration.
• Clock skew. The timestamp bounds how long a signed action is accepted, which limits the replay window even if nonce-tracking is lost. Pick an explicit acceptance window (say, a few minutes), reject anything outside it, and remember that an agent and its counterparty may run on hosts whose clocks differ — do not set the window tighter than your infrastructure's real skew.

These are not KXCO-specific; they are the standard hazards of any request-signing scheme. The reason to spell them out is that an autonomous agent amplifies them: a human retries a failed request and moves on, but an agent may loop, alert, or halt on a verification failure it cannot interpret. Build the three checks in from the first line and they never become a 3 a.m. incident.

Size and performance: what post-quantum actually costs you

Honesty about the trade is part of trusting the tool. An ML-DSA-65 signature is on the order of a few kilobytes, and the public key is similar — where an ECDSA signature is tens of bytes. For a single request this is negligible; the cost shows up at scale, in three places an agent architect should plan for: bandwidth (every signed request carries a few extra kilobytes), storage (if you retain signed actions for audit, budget kilobytes per action, not bytes), and on-chain footprint (which is exactly why you anchor a 32-byte digest rather than the full signature — see §05). Signing and verification themselves are fast — lattice operations are computationally cheap relative to their key sizes — so throughput is rarely the constraint; size is. The design response is consistent throughout KXCO: choose Category 3 rather than Category 5 to keep sizes down, anchor digests rather than payloads, and reserve the larger SLH-DSA signatures for the rare long-horizon artefact that justifies them. Plan for kilobytes and the economics stay comfortable across millions of actions.

05Settle and record on Armature L1

Signing makes an action unforgeable. It does not, on its own, make it permanent or give it an agreed order. For consequential actions — a settlement, a commitment, an event a counterparty will later rely on — the agent anchors the action to Armature L1, KXCO's post-quantum settlement network. Armature is quantum-safe from genesis (ML-DSA-65 signatures on the chain itself), has roughly two-second deterministic finality, exposes standard EVM tooling, and has a public explorer.

Because it speaks EVM, your agent uses the tooling you already know. Point it at the live RPC — always read the current parameters from the explorer rather than hard-coding them — and read or write like any other chain:

// connect a standard EVM client to Armature L1
// read live parameters (chain id, RPC) from https://chain.kxco.ai first
import { createWalletClient, http } from 'viem'

const armature = {
  id: 1111111,                         // Chain ID — confirm live on the explorer
  name: 'Armature L1',
  nativeCurrency: { name: 'ARMR', symbol: 'ARMR', decimals: 18 },
  rpcUrls: { default: { http: ['https://chain.kxco.ai/rpc'] } }
}

const client = createWalletClient({ chain: armature, transport: http() })

The pattern that matters most for agents is anchoring a digest, not storing data on-chain. You keep the signed action (and any private payload) off-chain; you write only its hash to the record. That gives you a permanent, ordered, tamper-evident timestamp for the action without publishing its contents:

// anchor the digest of a signed action to the public record
import { sha256 } from '@noble/hashes/sha256'

const digest = '0x' + Buffer.from(sha256(payload)).toString('hex')

// write the digest via your anchoring contract / precompile of choice.
// later, ANYONE can recompute sha256(payload) and match it against
// the on-chain anchor — proving the action existed by this block's time,
// unaltered, without you revealing the payload.

The reason to anchor rather than merely log is the same reason to sign rather than assert. A log is a private claim you ask others to trust. An anchor is a public fact anyone can check: the digest was recorded at this height, the order relative to other events is fixed, and no one — including you — can rewrite it after the fact. For an agent acting for someone else, that ordered, tamper-evident history is what makes "prove what the agent did, and when" answerable years later.

Batching anchors with a Merkle root

A busy agent may take hundreds of actions a minute, and anchoring each one individually is wasteful. The standard optimisation is to batch: collect a window of action digests, build a Merkle tree over them, and anchor only the single root. Each individual action can still be proven to have been included by presenting its Merkle path — a short list of sibling hashes — against the anchored root. You get one on-chain write for thousands of actions, and every action keeps an independent inclusion proof.

// batch many action digests under one anchored Merkle root
import { merkleRoot, merkleProof } from './merkle'

const digests = actions.map(a => sha256(canonical(a)))
const root = merkleRoot(digests)          // anchor THIS once on Armature L1

// later, prove action i was in the batch — no chain write, no KXCO:
const proof = merkleProof(digests, i)     // sibling hashes up to the root
// verifier recomputes root from digest[i] + proof and matches the anchor

This is the pattern to reach for when an agent's action volume is high but each action still needs an independent, durable proof — high-frequency settlement, per-message provenance, telemetry you may later need to attest. It keeps the on-chain footprint flat as volume grows, which is what makes anchoring economical at machine scale.

Finality, reorgs and what ~2 seconds buys an agent

For an autonomous system, deterministic finality is worth more than raw speed. On a probabilistic chain, an agent must decide how many confirmations to wait for before treating a settlement as done — a judgment call it is poorly equipped to make, and one that either adds latency or accepts reorg risk. Armature's roughly two-second deterministic finality removes that decision: once final, an action is final, and the agent can proceed without a confirmation-counting heuristic. That predictability is precisely what an agent needs, because it cannot "wait and see" the way a human operator intuitively does. Read the live finality and network parameters from the explorer before you design timing-sensitive logic — never hard-code assumptions about block times or chain ID that a page like this could let drift out of date.

06Judgment: screening what an agent does

An unforgeable, recorded action can still be a bad action. Signing proves authorship; it does not check sense. This is where judgment enters, and for agents it works at two levels.

The agent's own reasoning is the first level — the model deciding what to do. But a model's confidence is not a guarantee, and an agent will occasionally be wrong, manipulated, or working from stale data. So KXCO adds a second level: screening the agent's proposed action against a verifiable model of the world — the ontology — before it settles. The ontology links identities, ownership, authority, relationships and events into one structure, so a screen can ask questions a bare rules engine cannot: does this counterparty's stated backing actually exist? Is this within the authority the owner delegated? Does this action contradict something already recorded?

Concretely, the screen sits between "the agent signed an intent" and "the intent settles":

1. The agent signs its intent (§04). The signature makes the intent attributable and tamper-evident, so the screen is evaluating exactly what will settle — not a paraphrase.
2. The screen checks the intent against the ontology and the agent's scoped authority: limits, jurisdiction, counterparty risk, and internal contradictions.
3. A clean pass proceeds to settlement (§05). A contradiction is surfaced — returned to the agent or escalated — rather than silently swallowed. The point of judgment is to make the invisible failure visible.

The important design property is that judgment operates over verified inputs. A rules engine that screens data no one has cryptographically checked is guessing; a screen that reasons over signed, anchored facts is reasoning. Garbage that is signed is provably-authored garbage — the signature does not make it true — but at least the screen knows precisely what it is evaluating and who stands behind it. That is the honest boundary of the layer: it catches contradictions and out-of-scope actions; it does not bless the truth of well-formed inputs. Section 13 is explicit about that limit.

Why screening needs a graph, not a rules table

The reason judgment is anchored to an ontology — a connected graph of entities and relationships — rather than a flat rules table is that the interesting failures live in the relationships, not the individual fields. A rules table can check "is the amount under the limit?" It cannot easily ask "is this counterparty ultimately controlled by an entity the owner has already blacklisted three hops away?", or "does this asset's claimed backing trace to something that actually exists in the record?", or "does this action contradict a commitment the same owner made last quarter?" Those are graph traversals: they follow ownership, authority and event edges across many entities to find a contradiction that no single field reveals. Modelling the world as a graph is what lets a screen catch the fraud that is individually well-formed at every step and only wrong in aggregate — which is precisely the fraud an autonomous agent, checking fields one at a time, is most likely to wave through. The interactive graph in section 11 is a small instance of that same structure: identities, keys, authorities and actions as nodes, and the relationships between them as the thing you actually reason over.

07Using the KXCO products from an agent

Everything so far — identity, signing, settlement, screening — is the substrate. On top of it sit the products an agent actually uses to get work done. Each is reachable programmatically, and each treats an agent as a legitimate actor rather than a human it must pretend to be.

Two integration notes that save time. First, an agent authenticates to these surfaces the same way it authenticates anywhere on KXCO: by signing its request (§04), not by holding a product-specific API key. That means one identity works across every surface, and revoking or rotating the agent's key revokes it everywhere at once. Second, the wallet is self-custodial by the agent: KXCO does not hold the agent's funds or keys, which is the same non-custodial posture that applies to human users. KXCO is a software company; a licensed institution or the owner holds the relationship and any regulatory obligations. Design your agent's economics on that basis.

Machine-to-machine, not human-in-a-trenchcoat

The wider surface an agent can reach

The products above are the core, but the same identity-and-signing model extends to the rest of the KXCO surface, which is what makes "the Economic Operating System" more than a slogan for an agent builder. An agent can execute and countersign documents through the KXCO Sign capability — useful for a procurement or legal agent that needs to commit its owner to a supplier agreement with a signature that stays verifiable for a decade. In sectors with their own rails, the pattern repeats: a healthcare-oriented agent can operate within CareCredits (powered by KXCO); a treasury agent can act within the Treasury and Business OS layers, where payments, custody and banking resolve through the same ontology an agent already authenticates against. The consistent rule across all of them is that the agent presents one identity and signs one way, and the surface it is allowed to touch is a function of the authority delegated to it — not of how many separate API keys someone remembered to provision. Add a capability to an agent's remit and you widen its delegated scope; you do not bolt on another credential to leak.

The subtle win here is that an agent never has to impersonate a human to use the platform. It does not screen-scrape a dashboard, store a human's password, or click through a consent screen designed for a person. It presents its own identity, signs its own actions, and operates within authority that was explicitly delegated to it. When something goes wrong, the accountability trail points at the agent and, through the delegation edge, at the owner who scoped it — not at a shared service account that a dozen systems quietly use. That is what "first-class participant" means in practice, and it is only possible because identity, signing and authority were designed for agents from the start rather than retrofitted.

08Hosting your agents

An agent is only as trustworthy as the environment it runs in. A perfectly signed action is worthless if the runtime holding the signing key is compromised, or if the connection carrying it can be harvested today and decrypted later. So the hosting question is not incidental — it is part of the security model. KXCO's answer is Sentinel (PQC Host): a place to run agents where the transport, the deploy pipeline and the key custody are all quantum-aware.

Where the agent runs

Deploy the agent runtime as you would any container workload — the difference is what surrounds it. Sentinel runs on hardened infrastructure (the live network and hosting sit on DigitalOcean), terminates connections with hybrid post-quantum TLS, and integrates the attestation pipeline described below. You bring a container; the platform provides quantum-safe transport, signed deploys, and a home for the agent's key that is not a shared secret store.

# a minimal agent container — the runtime holds the ML-DSA-65 secret key,
# signs every outbound action, and never ships a bearer token
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
# secret key is injected at runtime into protected storage, NOT baked into the image
ENV KXCO_ALGO=ml-dsa-65
USER node
CMD ["node", "agent.js"]

Why hybrid post-quantum TLS matters for an agent

Transport uses hybrid key exchange — a classical curve and a post-quantum KEM (ML-KEM-768) together — so a break in either one alone does not expose the channel. For an agent this is not academic. An agent's connections carry signed actions, scoped-authority tokens and, sometimes, encrypted payloads. Under "harvest now, decrypt later," an adversary recording those connections today could decrypt them once quantum hardware arrives. Hybrid PQ-TLS closes that window now, and does it conservatively: you get post-quantum protection without betting the channel entirely on cryptography newer than the classical schemes it augments. It is the same posture major browsers and cloud providers are adopting.

Key custody: the one thing you must get right

The agent's secret key is the agent. Whoever holds it can act as the agent. So the single most important hosting decision is where that key lives, and the rule is simple: the secret key stays in the agent's runtime and is never a shared secret.

• Do not bake it into the image. A key in a container image is a key in your registry, your CI logs, and every host that pulls it. Inject it at runtime into protected storage.
• Do not put it in a shared environment variable or a broad secret store. The blast radius of a leaked shared secret is every agent that reads it. One key, one agent.
• Rotate by re-registering the public key. Because KXCO stores only public keys, rotation is: generate a new keypair in the runtime, register the new public key, retire the old. No secret ever moves.
• Encrypt anything the agent must persist with ML-KEM-768 + AES-256-GCM (the kxco-pq-vault package), so even at-rest data is quantum-safe.

Signed, scanned deploys

Before an agent goes live, its deployment is scanned for quantum-vulnerable cryptography and the resulting manifest is signed with ML-DSA-65 — binding the commit, the timestamp, the scan result and the deployment URL into a single verifiable artefact. That is what the CI edge in the topology above represents, and it is the bridge into the next section: quantum readiness is not a property you assert about your agent, it is one you measure and prove.

Running many agents: isolation and blast radius

A fleet changes the calculus. The governing principle is one key, one agent, one blast radius: each agent has its own identity and its own signing key, so a compromise is contained to that agent and is immediately attributable to it. Do not share a key across a pool of workers "for convenience" — that reintroduces exactly the shared-secret problem per-action signing was meant to kill, and it destroys the accountability trail, because you can no longer tell which worker acted. If you run agents as replicas of one logical identity, give each replica its own key registered under the same identity label, so an action is always traceable to the specific runtime that produced it while still resolving to one logical agent for a counterparty. Isolate runtimes at the container or network-policy level so a compromised agent cannot read another's protected key storage, and scope each agent's delegated authority to the narrowest set of actions its job requires — an agent that only reads should not hold a key that can settle.

Observability without leaking the payload

Agents need to be watched — you want to know what they did, catch anomalies, and reconstruct incidents — but naïve logging of an agent that handles sensitive data is a liability, and under "harvest now, decrypt later" a verbose log is a future breach. The pattern that squares this is to log proofs, not payloads: record the action's digest, its signature reference, the key id, the anchor height, and the screening outcome — everything you need to prove what happened and detect anomalies — while keeping the payload itself encrypted (ML-KEM-768 + AES-256-GCM via kxco-pq-vault) or out of the log entirely. A digest and a signature are enough to prove an action later; they reveal nothing about its contents. This gives you a rich, tamper-evident operational trail whose leakage costs you nothing, and it composes with the on-chain anchor: your logs and the public record agree, because both key off the same digest.

09Quantum readiness for agents

If you take one operational idea from this guide, take this: quantum readiness is a program, not a flag. You cannot flip a switch labelled "post-quantum." You have to know every place your agent — and everything it depends on — relies on cryptography, change the algorithms without rewriting the application around them, and prove to an auditor that you did. Most codebases have no accurate inventory: RSA and ECDSA are buried in dependencies, TLS libraries, container base images and code nobody has touched in years.

The threat is already live

The reason to start now rather than in 2030 is harvest now, decrypt later. An adversary does not need a quantum computer today to benefit from your using classical cryptography today. They record your agent's encrypted traffic and signed actions now, and break them the day the hardware arrives. Anything an agent signs or encrypts that must remain valid or confidential for years is already inside the exposure window. And the migration is calendared: NIST finalised FIPS 203/204/205 in August 2024; under current US guidance RSA and ECDSA are slated for deprecation around 2030 and disallowal by 2035. Agents deployed today will still be running — or will have signed things still relied upon — well inside those dates.

Inventory, then migrate

The practical program has a definite shape, and Bastion (part of Sentinel) is built to run it:

1. Scan. Run Bastion against the agent's repository and container image. It finds where you still use RSA, ECDSA, SHA-1, and quantum-vulnerable TLS — across your code and your dependencies.
2. Inventory (CBOM). The scan produces a cryptographic bill of materials — the crypto analogue of an SBOM — enumerating which algorithms live where, exported in a standard format. You cannot migrate what you have not inventoried; the CBOM is the map.
3. Migrate, hybrid-first. Move signing to ML-DSA-65 and key exchange to ML-KEM-768, keeping classical and post-quantum side by side so you can roll out incrementally and roll back safely. This is crypto-agility: the ability to change algorithm without changing the application, treated as a permanent property rather than a one-time cutover.
4. Attest. Sign the migration state so it is provable, not merely claimed. The signed manifest and CBOM turn "we're quantum-ready" into an artefact an auditor can verify.
5. Keep scanning in CI. A dependency update can reintroduce classical cryptography silently. Running Bastion on every build makes the migration a burn-down with evidence at the end, not a project that quietly regresses.

The interactive graph in the next section shows exactly what a Bastion scan surfaces: a repository whose dependencies pull in quantum-vulnerable primitives, and the post-quantum replacements each one maps to. It is the CBOM as a graph.

What a CBOM actually contains

A cryptographic bill of materials is not a vague "we use encryption" statement; it is a structured, machine-readable inventory, and knowing its shape helps you act on one. For an agent, a useful CBOM enumerates, per finding: the algorithm (RSA-2048, ECDSA-P256, SHA-1…), its role (signature, key exchange, hash, transport), where it lives (your code, a specific dependency and version, the container base image, a TLS configuration), its quantum status (vulnerable, deprecated, or already post-quantum), and the recommended migration target. Exported in a standard format, it becomes a shared artefact your security team, your auditors and your CI can all reason over — and, signed, it becomes evidence rather than assertion.

The reason this matters more for agents than for a static service is dependency churn. An agent is often a fast-moving codebase pulling in a wide surface of libraries — model clients, tool integrations, data connectors — any of which can quietly introduce a classical primitive in a routine update. A one-time audit goes stale the next time the lockfile changes. A CBOM regenerated on every build, diffed against the last, turns "did that dependency bump reintroduce RSA?" from a question nobody asks into a check that fails the pipeline. That is the difference between quantum readiness as a claim and quantum readiness as a controlled, evidenced state.

10A worked example: an autonomous procurement agent

Abstractions are easy to nod along to. So here is one agent, one task, traced through everything above. The task: an autonomous procurement agent, acting for a mid-sized business, negotiates and settles a recurring supplier payment — with no human in the loop, and with a proof trail that survives a decade.

1. Boot & identity (§03). On first start, the agent generates an ML-DSA-65 keypair in its Sentinel runtime, persists the secret to protected storage, and registers its public key with KXCO Verified as procurement-agent-01, subject type agent.
2. Delegated authority (§02, §03). The business owner delegates scoped authority to the agent: up to $5,000 per supplier per month, to counterparties on an approved list, in USD, expiring in 90 days. This is recorded as a relationship — owner —[:DELEGATES]→ authority —[:SCOPES]→ agent — that a counterparty can check.
3. Signed intent (§04). When a payment is due, the agent builds the exact action (payee, amount, nonce, timestamp) and signs it with its key. It sends the action and the signature — never a token.
4. Screening (§06). Before settlement, the action is screened against the ontology and the delegated authority: is the payee on the approved list, is the amount within the monthly limit, does anything contradict a recorded fact? A clean pass proceeds; a breach is surfaced to the owner rather than executed.
5. Settlement & anchor (§05). The payment settles via the agent's KnightsPurse wallet, and the digest of the signed action is anchored to Armature L1 with ~2-second finality. The event now has a permanent, ordered place in history.
6. Verification, by anyone (§04). Months later, the supplier, an auditor, or the owner's bank takes the signed action, the payload and the agent's public key, and checks the whole thing with kxco-verify — no KXCO server, no trust in KXCO required. "This agent, authorised by this owner within this scope, paid this amount at this time" is proven.
7. Quantum durability (§09). Because every signature is ML-DSA-65 and the transport was hybrid PQ-TLS, none of this becomes forgeable when quantum hardware arrives. The proof made at settlement is still a proof in 2036.

A second scenario: a diligence agent that answers on the record

The procurement agent moves value. This one moves information, and it shows the model works when the asset is a claim rather than a payment. A diligence agent is granted scoped, time-boxed access to a data room and asked to answer a counterparty's questions during a transaction — "confirm the entity's registration," "produce the signed board resolution authorising this deal." Each answer the agent returns is signed with its ML-DSA-65 key over the exact bytes of the response, and where the answer references a document, that document's existing signature and its Armature L1 anchor travel with it. The counterparty does not have to trust that the agent quoted the resolution faithfully: they verify the agent's signature over the answer, and independently verify the underlying document against its anchor. If a dispute arises later, the entire exchange — which agent said what, under whose authority, referencing which anchored documents, at what time — is provable with open-source tools and no dependence on KXCO. Access expires with the delegated authority; the proofs do not. It is the same four primitives, applied to trust in an assertion rather than a transfer, and it is why "prove what the agent did" is as meaningful for an agent that answers questions as for one that pays invoices.

What breaks without each primitive

Remove one primitive and watch the guarantee collapse. Without Trust (a bearer token instead of a signature), a leaked credential lets an attacker drain the supplier list, and no one can prove which actions were really the agent's. Without Judgment (no screen), the agent pays a look-alike payee it was manipulated into approving, and the fraud settles cleanly because it was well-formed. Without Record (a private log instead of an anchor), the payment history is one party's word against another's in a dispute. Without Permission (unscoped authority), a single compromised prompt lets the agent exceed every limit its owner intended. Each primitive is load-bearing; the composition is the product.

11Reference architecture — trace it yourself

The graph below is the live rendering engine we use across Sentinel and Treasury, loaded here with the agent model. Hover any node to inspect its type and properties; drag to rearrange; press Run scan to trace the flow outward from the agent, the way a proof propagates from a signed intent to an independent verification. It is the same relationships as the static diagrams above — Owner, Authority, Agent, Identity, Key, Signature, Judgment, Settlement, Verifier — rendered as the property graph the ontology actually is.

Interactive · drag nodes, hover to inspect, Run scan to trace the action flow. Rendering is illustrative; live network parameters are always at chain.kxco.ai.

Read the graph as three layers stacked into one. At the top, identity and authority: the owner, the scoped authority it delegates, and the agent that receives it. In the middle, trust: the agent's KXCO Verified identity and the ML-DSA-65 key it controls, which produces a signed action. At the bottom, the action's life: screening by the judgment layer, settlement on Armature L1, and verification by any third party. The reason to draw it as a graph rather than a flowchart is that these are genuinely relationships, not just steps — the same identity participates in many actions, the same key signs many things, and the same record is checked by many verifiers. That is what the ontology is: not a pipeline, but a connected model of who and what things are and how they relate.

12Build checklist — the on-ramps in order

You do not adopt all of this on day one, and you should not. Here are the on-ramps, roughly in order of effort, each standing on its own and composing with the next:

1. Verify first. Drop kxco-verify into a service and start checking signatures on inbound agent traffic. Zero infrastructure, immediate value, and it teaches the model.
2. Give your agent an identity. Generate an ML-DSA-65 keypair in the runtime; register the public key with KXCO Verified.
3. Sign every action. Replace bearer tokens with per-request signatures. Use the webhook adapters so it is drop-in.
4. Anchor what matters. Point at Armature L1 and anchor the digests of consequential actions.
5. Scope authority explicitly. Express what the agent may do as delegated, checkable authority — limits, counterparties, jurisdiction, expiry.
6. Host quantum-safe. Run the agent on Sentinel with hybrid PQ-TLS and runtime key custody; sign and scan the deploy.
7. Prove quantum readiness. Run Bastion in CI, produce a CBOM, migrate hybrid-first, and attest the result.

The same crypto-agility principle that governs the migration governs the adoption: you are never forced into a big-bang cutover. Start where the value is highest and the effort lowest — usually verifying inbound signatures — and add primitives as the agent's responsibilities grow.

Anti-patterns to avoid

The failures we see are rarely exotic; they are the same few shortcuts, taken under deadline pressure, that quietly undo the guarantees. Name them so you can catch yourself:

• Sharing one key across a pool of agents. It feels like a convenience and it is a regression: you lose per-agent attribution and you widen the blast radius of any single compromise to the whole pool. One key, one agent (§09).
• Baking the secret key into the container image. The key then lives in your registry, your CI logs and every host that pulls the image. Inject at runtime into protected storage.
• Signing but not verifying — or verifying but not checking the nonce/timestamp. A signature you never verify, or a nonce you never enforce, is theatre. The check has to actually run and actually reject.
• Re-serialising the payload before verifying. Verify the bytes you received, not a reconstructed object, or canonicalization drift will fail honest signatures (§04).
• Anchoring the whole payload on-chain. Anchor the digest; keep the payload off-chain and encrypted. On-chain is for proof of existence and order, not storage.
• Treating quantum readiness as a one-time task. A single migration that is never re-scanned regresses the next time a dependency updates. Keep Bastion in CI (§09).
• Giving an agent more authority "to be safe." Over-scoping is the opposite of safe. Delegate the narrowest authority the job needs; widen it deliberately, never pre-emptively.

Every one of these is a case of keeping the form of the design while dropping the property that made it worth adopting. If you find yourself doing one, the question to ask is which guarantee you are trading away, and whether you would say so out loud to the counterparty who is relying on it.

13What we claim — and what we don't

A guide like this is only worth trusting if it is honest about its edges. So, explicitly:

KXCO is a software company operating in the UK and USA. It holds no financial licences and does not custody assets or agents' keys. Licensed institutions that deploy KXCO software operate under their own licences and hold the relationships with their end customers. An agent's wallet is self-custodial; its key is the agent's, not ours.

Honest limits

Post-quantum cryptography is young. The lattice schemes are the best-analysed candidates humanity has, standardised after years of public scrutiny — but they are newer than RSA, which is exactly why transport stays hybrid rather than betting everything on them alone. Provable is not the same as true. KXCO can prove that a specific agent signed specific bytes at a specific time; it cannot make the content of an action honest. The judgment layer catches contradictions and out-of-scope actions; it does not bless inputs. The ontology is only as good as what is wired into it. Coverage grows deliberately, and undisclosed facts are marked undisclosed rather than invented. And the deadline cuts both ways: being early means building against standards and threat models that will keep evolving — which is why crypto-agility is a permanent property here, not a one-time migration. We would rather state these plainly than have you discover them and conclude the confident parts were oversold too.

14Frequently asked questions

Why does an agent need a cryptographic identity instead of an API key?

An API key is a shared secret: anyone who sees it can replay it, and the server must store it. A post-quantum identity gives the agent its own private key that never leaves it; each action is signed over its exact bytes, so a captured request cannot be reused, the server stores only a public key, and any third party can verify who acted and what they authorised without trusting the server. It is non-repudiable and quantum-safe — a bearer token is neither.

Where do I host an agent so it is quantum-resistant end to end?

On Sentinel (PQC Host): it terminates connections with hybrid post-quantum TLS, signs and scans container images before deploy with Bastion, and keeps the agent's key in its runtime rather than a shared secret store. The agent then reaches Armature L1, the verifier and other services over quantum-safe transport.

How do I make an existing agent quantum-ready?

Run Bastion against its repository and container to inventory every reliance on RSA, ECDSA and other quantum-vulnerable cryptography, and produce a CBOM. Then migrate signing to ML-DSA-65 and key exchange to ML-KEM-768, hybrid-first so you can roll back. It is a tracked program with a burn-down, not a single flag.

Can an agent hold and move money?

Yes — it can operate a self-custodial KnightsPurse wallet governed by its own key, within the authority its owner delegated, settling on Armature L1. KXCO is software; the institution or owner holds the relationship and any regulatory obligations. ARMR is a settlement unit, not a tradeable cryptocurrency, and nothing here is investment advice.

Do I have to trust KXCO to verify an agent's action?

No. Every signature is checkable offline with kxco-verify against the agent's published public key, and on-chain anchors are readable over standard EVM RPC. Verification does not route through KXCO, so an agent's past actions stay provable even if KXCO were gone.

What does "no lock-in" mean technically?

The signing and verification code is open source in four languages; the algorithms are public NIST standards; the record is a public chain with standard tooling; and you hold your agent's keys and signed artefacts. If KXCO vanished, everything your agent produced would remain verifiable with third-party tools.

Is this just a blockchain project with an AI label?

No. The chain is one of four primitives. On its own it records order and resists tampering, but it does not make signatures quantum-safe, does not exercise judgment, and does not model scoped permission for an agent. The value is in the composition, anchored by the ontology.