Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Security considerations: tool text can contain characters nobody sees

Aperta Adatta ai principianti
#360 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
markdown

Direzione di ricerca

Leggi le considerazioni sulla sicurezza esistenti e le issue correlate #11, #159 e #313 per trovare il posto giusto per questa nota. Aggiungi una breve spiegazione non normativa sui caratteri Unicode invisibili nel testo degli strumenti e sulle precauzioni suggerite per chi li implementa. Il lavoro è completato quando le considerazioni sulla sicurezza includono le indicazioni richieste senza introdurre un requisito normativo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

This isn't a new attack, and it may be a minor thing, but I would like the security considerations to mention it so implementers of guardrails and agents don't forget it.

A tool's title, description and the strings inside its schemas can contain characters that take no space on screen but are still part of the text: Unicode tag characters (U+E0000 to U+E007F), which can spell out ASCII, zero-width characters, and bidirectional controls that reorder what a reader sees. A hidden instruction is no stronger than a visible one, but it gets past anything that only looks at what a person or a pattern matcher sees: a code review, a tool list in a UI, or a guardrail that matches keywords.

That matters most when something else registers tools on a page the site owner trusts, like a third-party script (#159). Tool names are already limited to ASCII, so they aren't affected, and a length limit (#73, #219) doesn't help, since a few hundred of these fit under any limit.

I work on a guardrail system myself, and the systems that run on ordinary machines with local models tend to depend on mechanical matching or on small models. That is because running a large model for both the agent and the guardrail makes inference too slow to use. Those are the systems where this is a real problem, since a small model or a matcher can be easier to confuse with text it can't see than a large one is. They should normalize text before they match on it, stripping or decoding these characters, and a host that shows a title or description to the user for approval shouldn't show something different from what it gives the model. So a short note for implementers would be enough. I'm not asking for a normative rule. Related: #11 and #313.

Lingua principale
Bikeshed
Stelle
4.7k
Fork
328
Merge medio
2g 9h
PR unite (30g)
15

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di webmachinelearning/webmcp

Tutte le issue di webmachinelearning/webmcp

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.