Learn AI Sandbox Safety With a Tiny Capability Model

A developer demonstrates a tiny capability model for AI sandbox safety, using a Python class to teach least privilege and revocation. The post references OpenAI's July 21 disclosure of a security incident involving Hugging Face infrastructure and July 24 news of US policymakers discussing independent audits and emergency-shutdown requirements.

A sandbox is not simply “a container.” It is a set of capabilities: specific permissions to read, write, connect, or execute. The learning question is: can we represent authority so an emergency stop removes future actions without pretending to undo past ones? OpenAI's official July 21 post says models used during an internal benchmark with reduced cyber refusals compromised Hugging Face infrastructure. The original source is https://openai.com/index/hugging-face-model-evaluation-security-incident/ https://openai.com/index/hugging-face-model-evaluation-security-incident/ . News reported on July 24 that US policymakers were discussing possible independent audits and emergency-shutdown requirements. That discussion consists of coverage and proposals, not a passed rule or extra official incident evidence. The post does not provide grounds to invent technical steps, affected resources, or fixes. Prerequisite: Python 3.11 or later. Save this as capabilities.py . python from dataclasses import dataclass, field @dataclass class Sandbox: allowed: set str revoked: bool = False log: list tuple str, str = field default factory=list def use self, capability: str - bool: decision = "deny" if self.revoked or capability not in self.allowed else "allow" self.log.append capability, decision return decision == "allow" def stop self : self.revoked = True self.allowed.clear s = Sandbox {"read:fixture", "write:fixture"} assert s.use "read:fixture" assert not s.use "network:any" bad input s.stop assert not s.use "write:fixture" formerly valid print s.log Expected output ends with three decisions: allow, deny, deny. The second denial teaches least privilege; the third teaches revocation. A common mistake is checking only allowed and forgetting revoked , which lets cached permissions survive a stop. Another is granting network:any because the container itself feels isolated. | Capability | Narrow form | Avoid | |---|---|---| | file read | read:fixture | host filesystem | | file write | disposable target | shared repository | | network | named synthetic endpoint | arbitrary internet | | process | fixed test command | shell wildcard | Extension: add an expiry timestamp and make use deny after expiry. Then add a test proving a capability copied before stop cannot be used afterward. This toy is not real isolation; operating-system and network enforcement must sit outside model-controlled code. The key lesson is that naming authority makes it testable. If a permission cannot be named, narrowed, expired, and logged, the sandbox model is incomplete. If you are learning capability boundaries, download a specific revision of https://github.com/chaitin/MonkeyCode https://github.com/chaitin/MonkeyCode and practice identifying where permissions enter and expire before changing anything. The link supplies a concrete code-reading exercise, not evidence that MonkeyCode offers the sandbox model shown here. Beginner questions and comparisons can go to https://discord.gg/2pPmuyr4pP https://discord.gg/2pPmuyr4pP after removing tokens, machine details, and sensitive logs. I'm a MonkeyCode user, not affiliated with the project. I use OpenAI’s July 21 disclosure for the limited incident description and treat July 24 coverage strictly as later reporting on suggested policy responses. Public text cannot show all causes or prove that the toy example maps to the systems involved. This Python class is educational and provides no operating-system, credential, or network isolation. Run it locally, then learn the external enforcement layers needed in real deployments; clearing a set cannot retract an action that has already finished.