# Security considerations — DSDS 0.20.0

DSDS lets a document talk to an agent directly, in directive language. A `for: agent` section can carry what [AGENTS.md](AGENTS.md) calls "hard MUST/MUST NOT rules." And [Conformance](conformance.html) 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](conformance.html#conforming-consumer) 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](AGENTS.md#self-checking-your-work) 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](conformance.html#conforming-consumer)). 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](conformance.html#conforming-consumer)'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.