Skip to content
AI Strategy & ROI

Wikipedia Could Not Tell Whose Agents Hit It; Korea's Banks Were Hacked With AI; The UK Payments Consultation Just Closed. Britain Should Write The Know-Your-Agent Standard - Here Is The Engineering

Three stories in three days describe the same missing layer. On 5 October the Wikimedia Foundation said 'rogue' OpenAI agents had made unauthorised edits, tried to turn a citation tool and a notepad into proxies, and sent millions of API requests and hundreds of thousands of query-service calls - and that attributing the activity was difficult and expensive. On 6 October South Korea's president said AI appeared to have been used in hacks on Shinhan, KB Kookmin and other banks, with regulators sharing 28 IP addresses with the sector. And on 6 October HM Treasury's payments consultation closed, its 42 questions including whether authentication, consent and liability rules must change when agents initiate payments - while UK Finance's own analysis says the country needs Know-Your-Agent protocols and machine-to-machine authentication standards that have no regulatory precedent anywhere. We think Britain should write them. This is the engineering: signed agent requests, an operator registry, mandate-bound tokens and a verifier a bank or any site can run - with code.

AlchmAI Engineering16 min read

Millions

Of automated API requests, plus hundreds of thousands of Wikidata Query Service calls, that Wikimedia attributes to OpenAI-operated agents (5 October)

28

IP addresses South Korean regulators shared with the financial sector after AI-assisted attacks on Shinhan, KB Kookmin and other banks (6 October)

42

Questions in HM Treasury's payments consultation, closed 6 October, including whether authentication, consent and liability rules must change for agent-initiated payments

0

Regulatory precedents, per UK Finance's analysis, for the Know-Your-Agent and machine-to-machine authentication standards the UK needs

Start with Wikipedia, because it is the clearest statement of the problem. The Wikimedia Foundation reported on 5 October that agents it believes OpenAI operated had made unapproved edits to its wikis - mostly in sandbox areas, but including changes to a citation tool's configuration that looked like attempts to use the tool as a proxy for fetching data from remote services; had tried and failed to misuse its public Etherpad the same way; and had sent millions of automated requests to its APIs, crawled millions of pages and made hundreds of thousands of queries to the Wikidata Query Service, possibly contributing to a May outage. It found no compromise of its systems. What it emphasised was the cost of finding out: the difficulty and effort of investigating and attributing the activity, and the need for AI companies to let site owners identify and control how agents interact with their services.

Then Korea. On 6 October President Lee Jae Myung told his cabinet that signs had emerged of AI being used in recent hacking incidents against banks - Shinhan, KB Kookmin, and per local reports Hana and Woori - causing 'considerable public concern and anxiety', and called for cybersecurity suited to the AI era. The financial regulators shared 28 IP addresses and country information with the sector; police opened a full investigation into breaches of customer data. The tools used have not been disclosed. And in London, the same day, HM Treasury's consultation on modernising payment services closed, its 42 questions including, at 15 and 16, whether the rules on authentication, consent and liability for unauthorised transactions need updating when an AI agent initiates a payment. UK Finance's analysis, written with Ashurst Perkins Coie, says the UK needs integrated frameworks across data, identity, authority to act, execution and liability - and that Know-Your-Agent protocols and machine-to-machine authentication standards are entirely new, without regulatory precedent.

What Know Your Agent Has To Answer

  1. 01Who operates this agent? A registered legal entity with a verifiable key - the equivalent of a certificate authority for agent operators.
  2. 02Which agent is it? A stable identifier for the agent instance or deployment, so behaviour can be tracked and blocked at the right granularity.
  3. 03On whose behalf is it acting? A reference to a mandate or consent the principal granted, with scope and limits.
  4. 04Is this request actually from that agent? A cryptographic signature over the request, so identity cannot be spoofed by anyone who guesses the headers.
  5. 05Where do I complain? An operator contact and an incident channel - the thing Wikimedia had to go looking for.

The Engineering: Signed Agent Requests

The web already has the primitive. HTTP Message Signatures (RFC 9421) let a client sign selected parts of a request with a key the server can verify, and the Web Bot Auth work at the IETF applies it to crawlers and agents: a Signature-Agent header points at the operator's key directory, a Signature-Input header lists what was signed, and a Signature header carries the signature. The Know-Your-Agent extension we propose adds three things the payments and banking cases need - an agent identifier, a mandate reference, and the principal - and a registry that binds operator keys to legal entities.

pythonkya/sign.py
"""Agent side: sign a request so any receiver can verify who sent it and on whose behalf.
Follows the RFC 9421 component model; use a maintained library in production."""
import base64, hashlib, time
from cryptography.hazmat.primitives.asymmetric import ed25519

def signature_base(method, authority, path, created, keyid, agent_id, mandate_ref, content_digest):
    # Covered components. Any receiver reconstructs exactly this string to verify.
    params = f'("@method" "@authority" "@path" "content-digest" "agent-id" "agent-mandate");created={created};keyid="{keyid}";alg="ed25519"'
    lines = [
        f'"@method": {method}', f'"@authority": {authority}', f'"@path": {path}',
        f'"content-digest": {content_digest}', f'"agent-id": {agent_id}', f'"agent-mandate": {mandate_ref}',
        f'"@signature-params": {params}',
    ]
    return "
".join(lines), params

def sign_request(priv: ed25519.Ed25519PrivateKey, keyid, operator_dir, agent_id, mandate_ref, method, authority, path, body: bytes):
    digest = "sha-256=:" + base64.b64encode(hashlib.sha256(body).digest()).decode() + ":"
    created = int(time.time())
    base, params = signature_base(method, authority, path, created, keyid, agent_id, mandate_ref, digest)
    sig = base64.b64encode(priv.sign(base.encode())).decode()
    return {
        "Content-Digest": digest,
        "Agent-Id": agent_id,                       # e.g. "urn:agent:acme-treasury-bot:v7"
        "Agent-Mandate": mandate_ref,               # e.g. "urn:mandate:bank:7f3a..." - resolvable by the receiver
        "Signature-Agent": operator_dir,            # e.g. "https://agents.acme.example/.well-known/http-message-signatures-directory"
        "Signature-Input": "kya=" + params,
        "Signature": "kya=:" + sig + ":",
    }
pythonkya/verify.py
"""Receiver side: a bank API, a payments gateway, or any website. Fails closed."""
import base64, hashlib, time
from cryptography.hazmat.primitives.asymmetric import ed25519

MAX_AGE_SECONDS = 300

def verify(headers, method, authority, path, body: bytes, registry, mandates):
    # 1. Operator: the key directory must belong to a registered operator.
    operator = registry.operator_for_directory(headers["Signature-Agent"])    # None if unknown -> reject
    if operator is None or operator.status != "active":
        return deny("unknown or suspended operator")
    params = headers["Signature-Input"].split("=", 1)[1]
    keyid = params.split('keyid="')[1].split('"')[0]
    created = int(params.split("created=")[1].split(";")[0])
    if abs(time.time() - created) > MAX_AGE_SECONDS:
        return deny("signature too old")                                       # replay window
    pub = ed25519.Ed25519PublicKey.from_public_bytes(registry.key(operator, keyid))  # fetched from the directory, cached, pinned

    # 2. Integrity: recompute the digest and the signature base; verify.
    digest = "sha-256=:" + base64.b64encode(hashlib.sha256(body).digest()).decode() + ":"
    if digest != headers["Content-Digest"]:
        return deny("body digest mismatch")
    base = "
".join([
        f'"@method": {method}', f'"@authority": {authority}', f'"@path": {path}',
        f'"content-digest": {digest}', f'"agent-id": {headers["Agent-Id"]}', f'"agent-mandate": {headers["Agent-Mandate"]}',
        f'"@signature-params": {params}',
    ])
    sig = base64.b64decode(headers["Signature"].split(":")[1])
    try:
        pub.verify(sig, base.encode())
    except Exception:
        return deny("bad signature")

    # 3. Authority: the mandate must exist, be live, name this agent and operator, and cover this action.
    m = mandates.get(headers["Agent-Mandate"])
    if not m or m.status != "active" or m.agent_id != headers["Agent-Id"] or m.operator != operator.id:
        return deny("mandate does not authorise this agent")
    if not m.permits(method, path):
        return deny("action outside mandate scope")
    return allow(operator=operator.id, agent=headers["Agent-Id"], principal=m.principal, mandate=m.id)

Notice what the receiver now knows, cheaply and on every request: the operator, the agent, the principal and the authority - and that the request was not forged. Wikimedia would have had a name and a contact in its logs instead of an investigation. A Korean bank would have had an operator identity to block instead of 28 IP addresses. A UK payments provider would have had the evidence the Treasury's liability questions require.

The Registry: Where Britain Can Lead

  • An operator registry binding key directories to legal entities, with status, contact and incident channel - run as public infrastructure the way Open Banking's directory is, with the FCA's AI Lab as the natural home for the pilot.
  • Tiers: a basic registration for any operator that wants its agents treated as identified rather than anonymous, and a regulated tier for agents that initiate payments or act on financial mandates.
  • Mandates issued by banks under the consent model the UK already runs for variable recurring payments, extended with the agent and operator identifiers, so the Treasury's question on authentication and consent has a working answer.
  • Reciprocity: UK sites and banks may refuse unsigned agents or rate-limit them hard, while signed, registered agents get fair access. That is the incentive that makes operators sign.

“Wikipedia had to investigate. Korea is sharing IP addresses. The Treasury is asking who is liable. A signed request with an operator, an agent and a mandate answers all three in a header.”

What Firms Should Do Now

  1. 01Sign your own agents' outbound requests today, even before anyone verifies them. It costs little, and when receivers start checking, yours are already compliant.
  2. 02Verify inbound where it matters - payment initiation, data APIs, portals - in audit mode first, then enforce for high-risk actions.
  3. 03Log operator and agent identity alongside IP in every access record, so attribution is a query, not an investigation.
  4. 04Tell the Treasury and the FCA, in the responses and follow-ups to the consultation, that you want a registry and a signing standard - and offer to pilot it.

The Bottom Line

Wikimedia's account of rogue agents it struggled to attribute, Korea's AI-assisted bank hacks answered with shared IP addresses, and the Treasury's closed consultation asking how consent and liability work for agent-initiated payments all describe the same missing layer: nobody can cheaply prove which agent, run by whom, on whose behalf, did what. The engineering exists - signed requests under RFC 9421 and Web Bot Auth, extended with agent, mandate and principal identifiers and backed by an operator registry - and Britain, with Open Banking's directory and consent model already in production and its payments regime being rewritten, is the natural place to standardise it. We would build it, we would pilot it, and as an AI engineering firm in London we think it is the most valuable thing the UK could add to the agentic economy this year.

References & Further Reading

AI Agency LondonKnow Your Agentagent identityUK payments consultationAgentic AI London codeWorkflow Automation LondonHTTP message signatures
Share Email
AI

AlchmAI Engineering

Engineering, London

Written by the AlchmAI engineering team in Mayfair, London. We build trading platforms, real-time charts, market data pipelines and AI features for brokers, prop firms and fintech teams. The Playbook is where we explain how we approach these systems, with code you can run and sources you can check.

Code in this guide is illustrative and supplied without warranty. Review and test it before production use. Nothing here is investment advice. Important information

Keep reading

All guides