Your AI coding assistant just accessed your AWS credentials. Not because it was compromised, but because you gave it permission to "help with deployment." The issue isn't malicious intent; it's unrestricted access.
Hazmat, an open-source containment tool, represents a fundamental shift in AI agent security. Instead of trusting agents to behave, it assumes they won't and builds walls accordingly.
The Shift in Security Models
The security model for AI agents has changed. Traditional methods rely on prompt engineering, output filtering, and trust boundaries. Hazmat runs AI coding agents inside a separate user account on your machine, isolating them from your SSH keys, cloud credentials, and production access tokens.
This isn't theoretical. The tool is production-ready, and about 5.5 percent of its codebase is a formal specification written in TLA+. This means the containment logic is mathematically verified, not just tested.
Key Insights
Containment over monitoring. Logging every API call an AI agent makes is insufficient if it already exfiltrated your database password in request 47. Hazmat prevents access entirely. The agent runs in a sandbox that can't reach your ~/.ssh directory or environment variables containing secrets.
Session boundaries are critical. Before an agent starts work, Hazmat requires you to review session terms: what files it can access, what commands it can run, and what network calls it can make. This isn't a checkbox exercise. If you don't explicitly grant access to a directory, the agent can't touch it, even if a prompt injection tries to trick it.
Formal verification is essential. TLA+ is typically used for distributed systems and critical infrastructure. Using it for a developer tool signals that AI agent behavior is complex enough to require proof, not just testing. When containment fails, you don't get a failed unit test; you get exposed credentials in a public GitHub commit.
Open source as a trust model. Proprietary AI security tools ask you to trust their claims. Hazmat's containment logic is public, specified in TLA+, and auditable. You can verify that the sandbox prevents filesystem access before running an agent with access to customer data.
Implications for Your Team
If you're integrating AI coding assistants into your development workflow, you're accepting a new attack surface. The question isn't whether an agent will eventually try to access something it shouldn't, but what happens when it does.
Current controls assume human operators. SSH key management, AWS credential rotation, and secrets scanning all assume a person is making deliberate choices. AI agents make thousands of decisions per session. One bad decision, like accessing a .env file to "help debug," can expose everything.
Compliance frameworks lag behind. PCI DSS v4.0.1 Requirement 6.4.3 mandates that scripts and custom code are developed securely. Does that cover AI-generated code? What about AI agents that modify existing code? Hazmat provides a defensible answer: the agent ran in a restricted environment with no access to cardholder data.
Your incident response playbook needs an AI section. If an agent accesses sensitive data, what's your containment procedure? Hazmat's session logs show exactly what the agent touched, making forensics straightforward. Without containment, you're guessing based on model behavior and hoping your monitoring caught everything.
Action Items by Priority
Immediate: Audit current AI agent access. List every AI tool your developers use that can execute code or access files. Document what each tool can reach: filesystem paths, environment variables, network endpoints. If you can't enumerate it, you can't secure it.
Week one: Implement containment for high-risk workflows. Start with AI agents that touch production code, infrastructure configs, or anything containing credentials. Run them in Hazmat or build equivalent isolation using separate user accounts and filesystem permissions. Don't wait for a formal policy; protect the obvious risks now.
Month one: Define session boundaries as code. Create templates for common AI agent tasks: code review, test generation, refactoring. Each template should specify maximum permissions. Review these templates like you review IAM policies, because that's what they are.
Quarter one: Add formal verification to your security tooling roadmap. You don't need to learn TLA+ this quarter, but you should understand why Hazmat uses it. As AI agents become more autonomous, testing won't be enough. Start evaluating tools based on whether their security claims are provable, not just plausible.
Ongoing: Treat AI agents like junior developers with root access. Because that's what they are. They're helpful, fast, and occasionally catastrophically wrong. You wouldn't give a junior developer unrestricted access to production. Don't give it to an AI agent either.
The shift from "trust but verify" to "contain by default" isn't about distrusting AI. It's about recognizing that AI agents operate at a speed and scale where traditional security controls fail. Hazmat proves that containment is both practical and verifiable. The question is whether you'll adopt it before or after an incident.
