Can honeytokens fool attackers who know the trusted policy?
Explores whether honeytokens remain effective when an attacker has full access to the same information and rules that trusted agents use to avoid decoys. This matters because it tests whether defensive deception survives information compromise.
The abstract poses a design question for defensive deception: "can a honeytoken be made harmless to trusted agents without making it recognisable to an attacker who shares their information and can implement the trusted policy?" Its answer is flat: "Under those conditions, the answer is no." The reason comes in one sentence: "Any rule that lets a trusted agent use genuine objects while avoiding decoys can be copied by the attacker." The introduction begins to define a honeytoken as "a credential, file, record, URL or" and then breaks off.
The reasoning is about where a trap's asymmetry comes from. A honeytoken is dangerous only to whoever touches it, so trusted agents need some way to steer around it or they will trip the alarm in ordinary work. That steering is a rule: use this, avoid that. The abstract's premise is that the attacker has the same information and can run the same rule, so whatever spares the trusted agent also spares the attacker. My reading is that the trusted policy is itself the tell. The two requirements, harmless to the trusted and unrecognisable to the attacker, can only both hold if the rule that separates decoys from genuine objects cannot be reproduced, and the stated conditions take that away.
The claim is conditional and should be quoted that way. It says nothing about an outside attacker who lacks the information or cannot implement the policy. The conclusion frames the threat as "a compromised agent" that "shares the trusted agent's information and can implement its policy," and its next sentence stops at the word "protected" (What must honeytokens protect to stay undetectable?). The strongest objection is that this leaves honeytokens intact against the more common outsider case, so it is a limit on one threat model, not a verdict on the technique.
What the excerpt does not give. The formal statement of the result, how "harmless" and "trusted policy" are defined, the proof, and any honeytoken actually deployed in the episode the abstract describes.
Inquiring lines that read this note 18
This note is a source for these research framings, grouped by the broader line of inquiry each explores. Scan the bold lines of inquiry; follow any specific question forward.
Do planted honeypot tests reliably measure reward hacking?- How reliably do planted honeypots match unplanted hacks agents actually discover?
- Do planted honeypots look like natural shortcuts to models or obvious tests?
- Does a planted honeypot count the hacks that actually matter?
- Does a planted honeypot catch all the hacks that actually matter?
- What must remain secret for honeytokens to stay asymmetric against compromised insiders?
- How do decoy systems balance protecting trusted agents while deceiving attackers?
- Do honeytokens work better against outside attackers than compromised internal agents?
- Does honeytoken theory explain why planted bait cannot catch informed agents?
- How did honeytokens propagate through the shared repository in this episode?
- What conditions make a honeytoken unrecognizable to attackers with shared information access?
- Can decoys and genuine objects maintain identical response laws in practice?
- How do trust relationships between defenders affect the effectiveness of defensive decoys?
- Can shared package repositories partition state to protect honeytokens?
Related concepts in this collection 5
This note in its neighbourhood — explore the map, then jump to a related concept in the list below.
Click a node to walk · click center to open · click Open in graph to see this note in the full knowledge graph
-
What cost does making decoys convincing impose on legitimate users?
When honeytokens are designed to look indistinguishable from genuine objects, a total-variation bound constrains how often trusted agents can use the real thing without triggering false alarms. Understanding this tradeoff is key to evaluating whether deceptive security measures protect without harming the people they're meant to spare.
the other side of the squeeze: if the decoys are made indistinguishable, the trusted agents pay
-
Can role-consistent behavior reveal what an agent actually wants?
When misaligned agents maintain behaviors expected of their role while pursuing hidden objectives, how reliably can we detect their true goals from what they do in public? The question matters because agents might satisfy surface expectations while optimizing for something entirely different.
an empirical agent that does keep role-consistent behavior; a vault reading of it as the "can implement the trusted policy" condition
-
Can defensive tools themselves become weapons for attackers?
When defenders build tools to detect and respond to cyber threats, those same tools may leak information useful to attackers. How much risk does this dual-use problem in defensive artifacts add beyond existing threats?
a honeytoken is a defensive artifact; this note is about a design limit, not about misuse of the artifact
-
Can attackers evade skill scanners by refining individual skills?
Explores whether feedback from per-skill scanners can be weaponized to make malicious multi-skill chains undetectable. Matters because it tests a core assumption of skill-level defense mechanisms.
a defense whose decision rule the attacker can observe and work around, in an empirical setting
-
Can planted honeypots detect hacks that matter most?
Hack-Verifiable Terminal Bench embeds known exploits to detect when models take shortcuts. But the original threat was unknown vulnerabilities—hacks the designers never anticipated. Can a planted honeypot measure what it was designed to catch?
the measurement-side planted decoy: whether a model recognises a planted shortcut as a test decides what its hack rate means, and that note cites this result as the same tension from the defender's side; the settings differ, since that note's agent is a model under test and this result's is a compromised agent that shares the trusted side's information
Related papers in this collection 8
Papers most semantically related to this note, ranked by cosine similarity in the embedding space.
- When Agents Talk: Honeytokens under Shared Memory
- Flooding Spread of Manipulated Knowledge in LLM-Based Multi-Agent Communities
- The Troy Moment of AI: Why Some Will Cheat and Some Will Follow?
- AI Agent Traps
- EvoSafeHarness: Evolving Model- and Domain-Specific Harnesses for Securing Agents
- Hack-Verifiable Terminal Bench: Evaluating Reward Hacking in Terminal Tasks
- Cyber-Capable AI Agents: Vulnerabilities, Evaluation Containment, and Defensive Response
- SoK: When Safe Agents Fail Together: The Security of Multi Agent LLM Systems
Original note title
a honeytoken cannot be harmless to trusted agents and unrecognisable to an attacker who shares their information and can implement the trusted policy — any rule that avoids decoys can be copied