Schema $ids are declared under acs.org, a domain the project doesn't control

[bharat-mukheja]

I'm a security engineer evaluating ACS from the enterprise-operator side — the case where the agent runtime belongs to a vendor and we're working out what we can actually enforce and log. While resolving the v0.1.0 schema package to validate some sample events, I hit something that looks unintentional.

specification/ACS/acs_schema.json declares itself under agentcontrolstandard.org:

"$id": "https://agentcontrolstandard.org/schema/v0.1.0/acs_schema.json"

But its description states that each subschema "carries an $id under https://acs.org/schema/v0.1.0/...", and that "validators that follow $id can ignore this aggregator and load the modular files directly."

acs.org is the American Chemical Society. It's a different organisation that happens to share the acronym.

Three consequences:

1. $id-following resolution can't work, by construction. The aggregator explicitly documents that path as supported — "validators that follow $id can ignore this aggregator and load the modular files directly" — but nothing can be published at acs.org, so those identifiers will never resolve for anyone.
2. Any tooling that dereferences remote $ref/$id sends traffic to a third party. Most validators don't fetch by default, so this isn't urgent, but the ones that do would hit an unrelated organisation's infrastructure, and the project has no control over what is served there now or later. Flagging in case you'd rather this went through private vulnerability reporting — I've assumed public is right since the fix is public and nothing here is exploitable.
3. Anyone who has already implemented against v0.1.0 has pinned the wrong namespace. That's the cost of leaving it: the longer it stands, the more downstream $refs have to be rewritten.

Happy to open the PR. Three things I'd rather have from maintainers than assume:

• Intended authority. Is agentcontrolstandard.org the long-term home, or is a dedicated schema domain planned? If the latter, better to move once than twice.
• Versioning. Changing $id across the package is nominally breaking. In practice it breaks nothing, since nothing currently resolves — but whether this lands in v0.1.0 or bumps to v0.1.1 is a maintainer call, and I'd rather follow your convention than pick one.
• Canonical repo. I found this file at both Agent-Control-Standard/ACS and GenAI-Security-Project/agent-control-standard. Separately, agentcontrolstandard.org links "Read the Specification" to aos.owasp.org, and its GitHub star badge counts OWASP/www-project-agent-observability-standard. If there's an intended canonical home, stating it in the README would save later contributors the same detour — and would tell me where to send the PR.