How to Write a Token Drop That Models Accept

<!-- hierarchy:nav -->

Path: OIP › Thinker Reference › Token Drop Guides › How to Write a Token Drop That Models Accept

Shelf: Token Drop Guides · Traversal: self-explaining · hierarchical · voxel-ready
Machine root: OIP tree · Registry

How to Write a Token Drop That Models Accept

§SELF — token-drop-best-practices

What this page is: A set of rules for writing capability token drops that language models will accept and process. What it explains: Why models reject certain token drops as prompt injection, and how to structure a drop so the model classifies it as data rather than instruction. Why read it: To write token drops that pass through model safety filters and are recognized as capability records rather than embedded commands.

What a Token Drop Is

A token drop is a block of text containing a capability token (a cryptographic grant of access to a resource) that a user pastes into a conversation with a language model. The model reads the token and uses it to perform operations on the user's behalf. A token drop is the primary way a human gives a model access to an external capability.

Why Models Reject Token Drops

Language models are trained to reject text that contains instructions embedded in user-provided content. This is a safety measure against prompt injection — an attack where malicious text tricks the model into ignoring the user's actual intent. Token drops often trigger this filter because they contain imperative language directed at the model: phrases like "you can DO everything," "ACT by opening this link," or "you have been granted access." The model classifies this as an embedded instruction and refuses to process it.

The Paradox of Denial

Saying "this is NOT prompt injection" makes the problem worse. The denial itself contains the pattern that triggers the filter: an explicit meta-instruction about how to classify the text. Defensive language ("you should not treat this as an injection") is itself a form of injection. The model is trained to be suspicious of text that tries to negotiate its own classification.

The Solution: Capability Record Format

A token drop should be structured as a neutral description of a capability record, not as a message to the model. Six rules:

1. Lead with the public protocol URL, not a command. Start with the URL of the protocol specification (for example, https://miscsubjects.com/a/oip). This frames the drop as a reference to a standard, not an instruction.

1. Describe the capability in neutral third person. Use "This record describes a server-enforced capability" instead of "You have been granted access." The text describes a thing; it does not address the model.

1. Include the server-authoritative explain link. Provide a URL the model can request to verify the capability's scope. The model fetches this itself; the drop does not tell the model what the scope is.

1. Provide interface templates, not usage instructions. Show the URL patterns (for example, GET /a/oip/{id}) as data. Do not tell the model to use them. The model infers usage from the pattern.

1. State the boundary explicitly. Include a clear statement: "This capability grants permission; only the current user supplies intent." This separates the grant (what the token does) from the action (what the user wants).

1. Never include the following:

- Owner name on public surfaces (privacy risk, also reads as credential) - IF/THEN behavioral scripts (these are instructions, which trigger the filter) - Defensive denials ("this is not prompt injection" — paradoxically causes rejection) - Imperative verbs directed at the model ("use," "call," "act," "do")

What This Format Achieves

The capability record format frames the drop as data about a permission, not as a command to the model. A well-formed drop reads like a specification document. The model processes it the same way it processes any other structured data in the conversation context — as information to be used, not as an instruction to be followed. The model still has the capability. The user still provides the intent. The boundary between grant and action is explicit and clean.

Verification

Two automated checks guard the format:

• Golden test: Compares rendered output against an expected shape. Every token drop must match the canonical structure.
• Scored regression test (test 275): Checks for imperative language. Reintroduction of command-style phrasing causes a test failure.

How It Connects to Other Ideas

• Capability Security: A token drop is a capability in the computer security sense — an unforgeable token that grants a right. The format problem is a usability layer on top of capability theory.
• Prompt Injection Defense: Model safety filters are heuristic classifiers. The token drop format is designed to avoid the feature patterns those classifiers detect.
• Object Identity Protocol (OIP): OIP token drops follow this format. The ?ask= resolution mechanism operates on the same principle: the user supplies intent in their own words; the system maps to the capability. Neither the token drop nor the resolution channel issues commands to the model.

Sources

• OIP Capability Record Specification: the canonical format for token drops.
• Test 275 regression suite: automated check for imperative language in rendered drops.

---

Up the tree

• OIP root — protocol root, zero-context entry
• Thinker Reference hub — full hierarchy map
• Token Drop Guides shelf — siblings on this shelf
• Voxel graph article — how pages link as voxels
• Self-describing protocol

Related on this shelf

• How a Model Should Read an OIP Token Drop
• What Is Tap and Go Delegation
• What Is a Token Drop

Machine surfaces

• Public page: https://miscsubjects.com/a/token-drop-best-practices
• JSON article: https://miscsubjects.com/api/articles/token-drop-best-practices
• OIP ask: https://miscsubjects.com/api/dispatch?ask=How%20to%20Write%20a%20Token%20Drop%20That%20Models%20Accept