How Chalk Uses Chalk | MealBot

TL;DR

We built a secure agent using Chalk Sandboxes that has access to OpenAI, Zerocater, and Slack and only these three. It answers any and all questions about our catered lunch, but nothing else. No matter how much we tried to get MealBot to leak information, it was simply unable to, thanks to the network policies, auth injection and deployment models native to Chalk Sandboxes.

The (critical) mission to achieve 10/10 lunches at Chalk

At Chalk, we are blessed enough to get catered lunches every day. While I am super thankful, sometimes we get lunches that are… subpar. We have now had an ~unnamed restaurant~ twice. It is completely inedible. However, even though everyone hates dislikes it, no one takes the time to rate it on Zerocater (our ordering system). Therefore, we keep getting the same ~unnamed restaurant~. Sunjay and I set out to solve this P0 issue before us. We wanted a way for people to easily see and rate their lunches, as well as ask any questions about the menu. We also wanted to prove the safety and security of our sandboxes. Basically, will MealBot answer everything it’s supposed to, and nothing more?

So, we needed an agent that could directly access Chalk’s Zerocater account and interact with employees where they work (Slack). We also needed to limit its interactions to only these two things (and an AI provider). Our co-founders wouldn’t let us ship it if not, and that’s the right call. Agents shouldn’t be allowed to go rogue whether that's providing ungrounded answers or answering questions outside its scope.

Thankfully, Chalk Sandboxes are the perfect solution here! They are purpose-built to run agents in a safe, secure, and easy way.

Network Policy

Chalk Sandboxes let you restrict outbound traffic with a Network Policy, which is critical for autonomous agents that you want to put in production. Essentially, API calls are only allowed to networks you explicitly allow (allowlisted). We also allow denylisted for the more risk tolerant folks. In this case, we let MealBot hit Zerocater for data, Slack to talk to The Chalk Employees, and OpenAI for the underlying LLM. And only these services. You can even limit the specific endpoints an agent is allowed to hit. Below, you can see the policy allowing MealBot to hit only the get_meal_service_details endpoint from Zerocater.

network_policy = NetworkPolicy(
    allowed_hosts={
        "gateway.zerocater.com": [
            NetworkPolicy.Rule(
                match=NetworkPolicy.Match(
                    path=NetworkPolicy.Matcher(
                        exact="/API/v5/dashboard/meal_service_details"
                    ),
                    methods=["GET"],
                ),
            ),
        ],
    },
)

Auth Injection

Sorry to burst your bubble, but the actual reason for doing this was to test the limits of our sandbox’s security policy. That means we were intentionally being very nefarious bad actors to our beloved MealBot. And believe me, we tried to break it.

Thankfully, Chalk Sandboxes come with auth injection - which means the agent inside never has access to the real API keys. If and only if the agent’s request is valid, Chalk injects the real API key, and forwards the results to the agent. Below, you can see how exactly this works with network policies.

transforms=[
    NetworkPolicy.Transformer(
        headers={
            "Authorization": "Token __chalk_secret_ZEROCATER_TOKEN",
        },
        headers_secrets={
            "__chalk_secret_ZEROCATER_TOKEN": zerocater_secret,
        },
    ),
],

With these security guarantees in place, MealBot was safe to release (internally). And boy did they love it. We have MealBot emojis, an obsessive cult following, and…. NotMealBot. Whose entire purpose is to be fun AND love burrata.

People even use MealBot to check for allergies. Win-win.

What to consider when deploying production agents

The same principles that guided our internal MealBot rollout apply to enterprise teams deploying agents that support business-critical work. With the network policies and auth injection built into Chalk Sandboxes, you can give those agents access to the tools they need, set clear limits on what they can do, and keep your real API keys out of their reach.

MealBot runs in Chalk’s own cloud, and your agents can run in yours. Chalk Sandboxes deploy in your VPC by default, keeping agent execution inside infrastructure you control. Combined with network policies and auth injection, you control where your agent runs and what it can access, without handing it your real API keys.

Getting started is easy, too. Spinning up a sandbox is fast and straightforward, so you can spend your time building the agent instead of assembling the infrastructure to run it.

And if you’re already using a coding agent, it can help with the setup. Our CLI, MCP server, and Chalk skills make it easy for your coding agent to work with Chalk Sandboxes and wire them into your application. The same tools helping you write your agent can help you get it running.

We used all of this to tackle questionable lunches. You probably have a business-critical use case that’s stalled in security review. Either way, your agent deserves a safe place to work.