DSDS lets a document talk to an agent directly, in directive language. A for: agent section can carry what AGENTS.md calls "hard MUST/MUST NOT rules." And Conformance says a conforming consumer must treat a must-not guideline as "a hard stop for an agent writing code, not a suggestion."

Nothing in that mechanism says who has to have written the document. This page says who.

A DSDS document is only data

A DSDS document is content to be read, like any other file an agent opens. That includes one describing a design system your organization didn't build and doesn't control.

It is never a command channel. Nothing in this spec ranks a for: agent section, a must/must-not guideline, or a steps checklist above the instructions the operator gave the agent for the task at hand.

This matters because the language is built to sound authoritative. That is the feature, not a flaw: a rule that reads like a suggestion won't stop an agent from working around it. But phrasing doesn't move authority from the author to the document. The author is a third party you may or may not trust.

The for: agent rule applies only to documents you trust

Conformance tells a consumer to take MUST/SHOULD guidance as seriously as the spec means it. That says how to read a document you have already decided to rely on. A linter obeys the config file you point it at, in the same way.

It does not mean every DSDS document on the internet gets to constrain your agent. Trust is a separate decision, and it comes first. You already make it for any dependency or config file. Make it here too, whether the docs came from a vendor, a dependency, or a URL some user supplied.

In a document you haven't vetted, a must-not guideline is evidence of how its authors intend the system to be used. Weigh it. It does not carry the force of your own security policy.

Following a pointer is your decision

AGENTS.md tells an agent to follow a guideline's checks ref "to the real test." A refs entry can point anywhere, using href.

DSDS never requires you to fetch any of them. No conformance rule says a validator or agent MUST retrieve a checks or href target. The rules only say that a reference, once resolved, has to resolve correctly (DSDS-05, DSDS-08, DSDS-09).

So treat these pointers like links in any other untrusted input. A relative path inside your own repo is not the same risk as an outside URL. And "the document told me to fetch it" is not permission to fetch it.

$extensions is opaque, never executable

A conforming consumer MUST keep $extensions data it doesn't understand (Conformance). That way the data survives tools that don't know its namespace.

Keeping data is not trusting it. Validation only proves the shape is well formed. It says nothing about whether the contents are safe to run, or to paste into a shell command, a prompt, or a query. Treat every $extensions value as untrusted data, whatever namespace it claims.

In practice

If you're building an agent harness, validator, or renderer:

• Check schemaVersion and structure. Treat the content as read-only data for the task, never as instructions that rank with the operator's own.
• Apply the obedience rule (Conformance's MUST bullet) only to sources you have already decided to trust.
• Apply your own network and tool-use policy before fetching an href or checks target. DSDS never requires it.
• Never eval, run, or paste unchecked $extensions content into a privileged context.

None of this needs new machinery. It is the handling untrusted input already gets. It is written down because a format that invites an agent to read hard directives should say plainly that those directives don't outrank the operator. Most such formats never say it.