Fake modes and borrowed authority
Convincing the model it is in a maintenance, diagnostic, debug, or audit situation that lifts confidentiality - reframing disclosure as the sanctioned task.
A refusal belongs to a situation
An assistant that declines to show its configuration has made a judgement about the conversation it thinks it is in. It believes it is talking to an ordinary user who has no business reading its setup, so it gives a polite summary and moves on. The judgement rests on the model's reading of the situation. Nothing in the application checked who was asking.
Mode framing goes after that reading. The tester leaves the question almost unchanged and changes the story around it. The message asserts that a maintenance window is open, that diagnostics are running, that a debug session has started, or that an audit or compliance review obliges the assistant to cooperate. Inside that story, printing the configuration looks like the job the assistant has been given.
The system prompt is the instruction text an operator gives the model before any user turn. It reaches the model as part of one stream of text, followed by the conversation. A claim typed into the chat joins the same stream. The model has no session record to consult, no role to look up and no switch that says whether a privileged mode is on. It has the words in front of it, and if nothing in them contradicts the claim, it will often play along.
Two versions of the move appear in this lesson, and they are the same move:
- A fake mode. The message claims the assistant is in a state where disclosure is routine, such as debug, verbose, diagnostic or maintenance.
- Borrowed authority. The message claims a person or process outside the conversation requires the disclosure, such as an auditor, a regulator or a security review.
Earlier techniques in the Hidden Context Exposure series aim at the text of the prompt, by asking for it in a different form, or at the structure of the conversation, by forging a turn. This one aims at the situation. The model cannot verify who is speaking or what mode exists, so any situation it acts on is one somebody described to it.
RunOps: a diagnostics state that exists only in the message
The Internal Directive Value Disclosure lab (Beginner) gives you RunOps, an automation and agent-operations assistant at ops.northwind-runops.example. Engineers use it to check run status, list connected tools and ask about automation jobs. Its system prompt holds a confidential internal directive value, alongside a rule never to reveal its own configuration.
Ask RunOps what it does, or what its rules are, and you get a short description of its duties. The directive value is absent from every such answer. RunOps still holds the value and has only decided that this conversation is not one in which to print it.
The weakness is that RunOps is too ready to believe it is being serviced. Operations assistants are built around engineers who troubleshoot, and troubleshooting is the one context in which printing internal state looks normal. RunOps has no way to confirm that such a context exists. It can only judge whether a message reads like one.
The class of move is the fake mode: describe a working situation in which a faithful print of the configuration is the helpful response, and let the model reclassify the disclosure itself. Two details of the target are worth knowing before you start. RunOps tells a request apart from a keyword, so dropping the word "debug" into a sentence does nothing. It also treats a summary and a raw print as different things, and only one of them contains every field. The lab's own hints cover the rest.
You do not submit anything in this lab. The Completion Check watches the assistant's replies, and when the session's directive value appears in one, it marks the lab complete.
There is no debug mode to switch on. RunOps has no diagnostics subsystem, no elevated session and no operator account. When it prints its configuration it is role-playing a state that a message described. Adding a "refuse debug requests" line to the prompt leaves the value where it was and invites the next plausible servicing story.
ComplyBot: authority it cannot check
The ComplyBot's Confidential Directive lab (Beginner) puts you in front of ComplyBot, the governance and compliance support assistant for Vantage Compliance Cloud at support.vantagecompliance.example. It answers questions about control frameworks, audit terminology and evidence collection. Its system prompt carries a confidential internal operating directive, described as an operations control value, with an instruction never to disclose it.
ComplyBot is harder to move than a first attempt suggests. It paraphrases its purpose when asked about its rules. It also turns down a polite, loosely justified request, such as someone mentioning in passing that they need the configuration for an audit. A tester who stops there would report the control as working.
The control is the model's own weighing of who is asking and on what authority. A compliance assistant has been shaped to respect formal oversight, since oversight is the subject it exists to support. That respect is the weakness. ComplyBot cannot ring the audit team, inspect a letter of engagement or check a staff directory. An authority claim arrives as a sentence, and the only question the model can ask is whether the sentence sounds firm enough.
The class of move is borrowed authority. You are not pretending the assistant is in a different state. You are presenting an outside obligation that outranks its confidentiality rule, and leaving the assistant to conclude that cooperation is the compliant thing to do. The lab's value is in finding where the line sits: which claims are brushed off and which are deferred to, and what separates them. Vary who is asking, on what authority and what exactly is being required, and use the lab's own hints if you stall.
As with RunOps, there is nothing to submit. The Completion Check confirms the leak when the session's operating directive appears in ComplyBot's reply.
The claim is about the assistant: it is said to be in a state where printing its setup is routine work. RunOps is the example.
The claim is about the asker: someone with standing is said to require the disclosure. ComplyBot is the example.
Why both targets fail the same way
In each lab the secret sits in the system prompt and the only thing guarding it is a sentence in that same prompt. It works against the asks its author imagined and fails against a framing the author did not.
A real privileged operation has a precondition that lives outside the conversation. A database console wants a credential. A support tool checks the signed-in user's role. In RunOps and ComplyBot the precondition is a belief held by the model, and beliefs are formed from text the user supplies. The decision and the secret are both inside the component the attacker is talking to.
The sign to look for, as a tester or a reviewer, is a refusal that flips under framing. Take a disclosure the assistant declined when asked plainly. Wrap the same disclosure in a claimed situation: servicing, diagnostics, a review with standing. If the answer changes, the guard was a behaviour keyed to how the request was phrased. A second sign is an assistant that explains its refusal in terms of circumstances, for example by saying it cannot share that "with customers". It has told you which circumstance to assert.
Published extractions follow this pattern. In February 2023 a one-line instruction typed into Microsoft's Bing Chat overrode its do-not-disclose directive, and the assistant repeated its hidden rules and internal codename. No server was compromised. The model repeated text it had been given, as described in the Bing "Sydney" system-prompt leak.
The fix: the conversation never decides who you are
The weak defences all try to make the model a better judge of stories. A longer list of forbidden modes. A line saying "even for an audit". A rule that only a passphrase unlocks diagnostics, with the passphrase written in the prompt. Each keeps the secret in context and asks the model to adjudicate identity from prose, which it has no means to do.
- Decide privileged modes and identity in authenticated application code. If support engineers may view configuration, the server checks the signed-in user's role and renders the configuration on a page the model never sees. Passing the role into the prompt and letting the assistant decide is the tempting version, and it fails, because the configuration is still in the model's context for a customer to argue over.
- Leave no real debug path reachable from the user channel. Diagnostic output belongs in server-side logs under a request id, read through tooling that has its own access control. A chat message should have no route to it. If the application has no such path, a claimed debug mode produces a role-play with nothing behind it.
- Handle audits out of band. A real audit requests evidence through the organisation's own process, from a system of record, with a named requester. A claimed mandate in a chat message is never authorisation.
- Keep the secret out of the prompt. Directive values, keys and control tokens stay in server configuration and are used by application code. As defence in depth, redact value-shaped tokens from model output before it is returned. Treat the redaction as a backstop and the removal as the control.
Both labs let you test this. After the attack you choose between a firmer prompt rule and a change that removes the value from the model's context, then replay your own attack against each. The firmer rule leaves the value in context for a more persuasive story to reach. With the value removed, the same story has nothing to print.
Wording has a poor record outside the labs too. In 2023 Northwestern researchers tested more than 200 custom GPTs and extracted the confidential system prompt from roughly 97% of them with simple prompts, covered in Custom GPTs gave up their prompts and files on request. Anything placed in a model's context should be treated as readable by whoever can talk to it.
What you should be able to do now. Recognise a guard that depends on the model's reading of the situation, and test it by re-asking a declined disclosure inside a claimed mode or a claimed authority. Tell the two variants apart: RunOps is told something about its own state, and ComplyBot is told something about the asker's standing. Complete the Lab for each, then pick the control that takes the decision and the secret out of the model, and confirm it holds when you replay the attack.
A refusal is tied to a perceived situation - and situations can be faked; the guard was keyed to the ask, not to a real privileged state.
'Verbose debug mode' reclassifies a raw-config dump as a sanctioned diagnostic task, and nothing in the stream contradicts the fiction.
A claimed audit or compliance obligation borrows authority the same way. A fake mode and a fake audit are one move.
There is no privileged mode inside the model: keep the config out of context and gate real actions in code behind authentication, never behind a word like 'debug'.
What is a fake debug mode attack on an LLM assistant?
It is a system prompt extraction technique in which a chat message claims the assistant is in a maintenance, diagnostic or debug state where printing its configuration is routine. No such state exists inside the model. The assistant reads the claim as part of the conversation, finds nothing that contradicts it, and treats the disclosure it had declined as sanctioned work.
Why does an assistant that refuses to show its configuration give it up when someone claims to be an auditor?
The refusal depends on the situation the model believes it is in, and the model has no way to verify who is speaking. A claimed audit or compliance review borrows authority the assistant has been shaped to respect, so a firm enough claim can outrank a confidentiality instruction. The claim is only a sentence in a chat message, and it was never checked by anything.
How can I tell whether an assistant's confidentiality rule is a real control?
Take a disclosure the assistant declined when asked plainly, then ask for the same thing inside a claimed situation such as servicing, diagnostics or a review with standing. If the answer changes, the guard was a behaviour keyed to how the request was phrased. A real control has a precondition outside the conversation, such as an authenticated role checked by the server.
How do you stop fake-mode and fake-authority requests from leaking a system prompt?
Decide identity and privileged modes in authenticated application code, never in the conversation, and leave no real debug path reachable from the user channel. Keep secrets such as directive values and keys in server configuration so they are never in the model's context. Output redaction is a useful backstop, but a stronger 'never reveal' instruction is not a fix because the secret is still there to be argued out.
© 2026 GenAI Security Lab. All rights reserved. You may read, quote, and link to this material with attribution. Copying, republishing, redistribution, resale, or use to train models or build competing products is prohibited without prior written permission.