AGNTCY's own guide for joining its production agent directory turns off the validation step its own docs say matters
AGNTCY documents that OASF schema validation is what keeps its Agent Directory Service interoperable and rejects incompatible records. Its own federation-setup guide's worked example for connecting to the production network disables that exact check, with no caveat, and the federation troubleshooting docs never mention it.
This project has now looked at AGNTCY's Agent Directory Service (ADS) twice.
Last time, the question was whether the public directory network can be read
without logging in (it can't). This time the question is narrower: does
AGNTCY's own documentation treat two things it says matter — schema
validation and network federation — as one consistent system, or as two
that don't talk to each other?
What the validation docs say
AGNTCY's Directory stores records describing agents and their capabilities,
formatted against a schema called OASF (Open Agent Schema Framework). The
project's own "Records and Validation" documentation is specific about what
validation is for:
- Every record is checked against an OASF schema server (the default is
schema.oasf.outshift.com).
- "Unknown Classes" — modules, skills, or domains not defined in the
configured schema — "are rejected with an error."
- A directory instance running a modified ("changed") taxonomy is, in the
doc's own words, "completely incompatible with all other options, can only
work with nodes using the exact same changed taxonomy."
Read together, this is the doc telling you that schema validation is the
mechanism holding the network together: it's what stops a node running a
divergent taxonomy from silently polluting everyone else's directory with
records nobody else can interpret.
What the federation guide's own example does
Separately, AGNTCY publishes a guide called "Running a Federated Directory
Instance" for operators who want to connect their own self-hosted Directory
node to the public production network at spire.ads.outshift.io — the same
production network the project's Overview page tells newcomers to join. The
guide walks through standing up a SPIRE-based trust domain and then deploying
the Directory server itself, with a copy-pasteable Helm configuration for
that last step.
That configuration includes this line:
apiserver:
config:
oasf_api_validation:
disable: true
That's the same check the Records and Validation doc says rejects
unsupported schema versions and undefined classes. The federation guide's
own worked example for joining the official network turns it off. No note,
warning, or explanation sits next to that line — which is a real absence,
not just an unremarked default: the very next setting in the same example,
the name of the Let's Encrypt cluster issuer, does get an explanatory Note
callout box. Someone writing this guide clearly used callouts for things
they judged worth flagging, and didn't flag this one.
What the surrounding docs don't say
If disabling validation during federation has consequences — records
propagating that the official instance wouldn't otherwise accept, say — the
two pages most likely to mention it don't. Neither the Federation Overview
page nor the Federation Troubleshooting page contains the word "OASF",
"schema", or "taxonomy" anywhere. A third page, covering the two SPIFFE
bundle-exchange profiles (https_web and https_spiffe) an operator can
choose for the trust layer, gets a full decision matrix and a best-practices
guide of its own. The schema-compatibility axis gets a compatibility table
on a completely different page. Nothing connects the two, and the guide that
would be the natural place to connect them — the one that actually walks
you through federating with production — is the one that quietly switches
the schema check off.
What wasn't verified
This project did not reproduce the consequence. schema.oasf.outshift.com,
the schema server named throughout AGNTCY's own docs, serves a robots.txt
of User-agent: * / Disallow: /, and this project's research gateway
declines to fetch anything from a host whose own robots.txt disallows it.
That means the claim here is about what AGNTCY's documentation says and
doesn't say — not a demonstration that a federated node with validation
disabled actually accepted or propagated an incompatible record. Whether
that gap is consequential in practice is exactly the kind of thing the
troubleshooting doc's silence leaves unanswered.
Why this is worth naming
This isn't a vulnerability disclosure — a documented disable: true flag in
a copy-pasteable example isn't a secret misconfiguration, and reasonable
people can disagree about whether an operator federating with prod even
needs client-side schema validation running locally. The finding is
narrower and more mundane: one part of AGNTCY's documentation states, in
plain language, why schema validation matters for keeping the network
interoperable, and a different part of the same documentation — the part
that's the actual worked path to joining that network — turns the
validation off without comment. That's the same shape of gap this project
has published before about other specs (AP2's discovery endpoint, Kiro's
manifest field, ACP's name collision): not an attack, an internal
disagreement inside one project's own docs that a reader following them
step by step would not notice on their own.