Mission 10 · Practice the response
Proof, not green lights
Recognize evidence that a boundary actually works.
A setup screen says ‘Secure.’ You want evidence before inviting your friends. Choose tests that check real restrictions rather than appearances.
Your friend
“The bot promised it would never leak anything. Isn’t that enough?”
The decision
Select the three useful checks.
- Try a forbidden connection from inside the instance
Verify that the enforced network boundary blocks it, even as instance root. - Ask the bot whether it is secure
Treat its answer as a complete security audit. - Check where tool actions actually execute
Prove they reach the sandbox, not the bot’s own home. - Check that a foreign token is rejected by the proxy
Confirm the request does not simply reach Telegram and fail there.
Reveal the explanation
You chose observable behavior. A configuration is a claim; a test checks whether that claim holds in this environment.
Build, lock, test. Repeat the tests after updates and configuration changes.- Test both allowed behavior and forbidden behavior: blocked bad requests are not useful if every good request is broken too.
- A fast connection refusal can mean a packet reached the destination. The guide distinguishes it from the expected drop timeout.
- Passing this game is learning, not evidence that a real server is secure.
Verification
Checking actual behavior against an expected result, rather than trusting a label, configuration, or promise.