One signing key, thousands of customers: a new IETF draft says agent platforms cannot be trusted per-tenant today, and proposes a signed sub-identifier to fix it.
What happened
On 2 November 2026, Rim Vilgalys and Pablo Gonzalez of Google published draft-vilgalys-webbotauth-signed-agent-metadata-00 in the IETF’s Web Bot Auth work. It is Standards Track, 15 pages, and expires on 6 May 2027.
Web Bot Auth — the base protocol is draft-ietf-webbotauth-httpsig-protocol — lets an automated HTTP client sign its requests with HTTP Message Signatures (RFC 9421) and point the server at its public keys through the Signature-Agent header. That works when one organisation runs one crawler. It breaks when a hosted agent platform runs thousands of customer workloads behind a shared egress and signs all of them with the same platform key.
The draft states the resulting problem plainly. If one tenant scrapes aggressively, the origin sees malicious traffic that is cryptographically authenticated as the platform. The verifier then has two bad options: penalise every tenant on that platform, or let the platform-level abuse through. The authors call this “shared fate”.
Their fix is a new header, Signed-Agent-Metadata, defined as an RFC 9651 Dictionary with three optional members:
- product — the agent software or application under the signing platform.
- project — an opaque identifier for the tenant account, workspace or billing project.
- session — an ephemeral identifier for one bounded task run, workflow or browser context.
The values are scoped namespaces, not global identifiers. They nest strictly: Signature-Agent, then product, then project, then session. The same session string under two different projects counts as two different sessions, and a verifier must evaluate a narrow identifier inside the namespace of every broader one present.
Two rules make the header usable rather than decorative. It has to be inside the signature: the platform adds signed-agent-metadata to the Signature-Input covered components, and a verifier must ignore the header if it is not covered. And it has to come from the platform, not the tenant: platforms should populate the members from authenticated platform state, and should overwrite, namespace or validate them at the signing boundary — otherwise a customer can claim a competitor’s product or project and either inherit their reputation or poison it.
The draft also confronts the obvious gaming move. A tenant with a bad reputation can cycle fresh session and project identifiers on every request to reset its standing. Verifiers should treat newly seen identifiers as neutral rather than trusted, and track how fast new sub-identifiers appear under each parent; high churn under one parent is itself a reason to apply policy at the parent tier. Privacy gets the same treatment: no personal data in the header, opaque tokens only, and session values scoped per target origin (a keyed HMAC over the internal session ID and the target authority) so two sites cannot correlate one session.
Four questions are left open for the working group at IETF 127, including the field name itself and whether a fourth tier is needed between project and session to represent “a specific deployed agent, sub-tenant, or credential”.
Why it matters for KYA
It draws the line between platform identity and agent identity. A signature that proves “this request came from Acme’s agent platform” answers almost nothing a KYA policy needs. Which product, which tenant, which run, and under what authority are separate questions. This draft adds the middle of that chain and deliberately stops short of the last one: nothing here says what the agent was authorised to do, only who it is downstream of.
It is a worked example of a KYA rule that keeps getting broken: an identifier the subject can set is not evidence. The platform attests the tenant, and the tenant cannot attest itself. The security section spells out what happens when that is reversed — cross-tenant spoofing, reputation theft, and traffic attributed to the wrong principal. The same failure mode appears wherever agents self-declare their own identity, scope or owner.
Reputation becomes part of the identity, and part of the attack surface. KYA’s trust-history leg needs a stable handle that survives key rotation. The draft’s stability rule (product and project fixed for the life of the workspace, session fixed per task) is what makes any trust signal accumulate at all. It also means identifier churn is a signal, not noise.
The privacy trade-off is explicit rather than hidden. Origin-scoped session IDs give a verifier continuity on its own site without handing it a cross-site tracking key. That is the shape any agent-identity scheme should aim for: enough to make an accountability decision, not enough to build a profile.
What to watch
Whether Web Bot Auth’s working group adopts a sub-identity model at all, and in what form — the open questions suggest the tier between tenant and session is contested, and that is the tier a deployed agent would occupy. Also watch whether the Signature Agent Card work (draft-meunier-webbotauth-registry) picks up a declaration of which keys a platform signs, since a verifier deciding whether to trust a sub-identifier needs to know what the platform promised.
Sources
- IETF, draft-vilgalys-webbotauth-signed-agent-metadata-00, “The Signed-Agent-Metadata HTTP Header Field for Web Bot Auth”, 2 November 2026 — datatracker.ietf.org
- Full draft text — ietf.org
- IETF, draft-ietf-webbotauth-httpsig-protocol (base Web Bot Auth protocol) — datatracker.ietf.org
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.