Agents And Tool Use hard
A data-analysis agent runs model-written Python in a container on the application host. So the code can query data, the container inherits environment variables that include read-write production database credentials, and it has open network egress. Security review blocks launch. Which change best fixes the risk?
- A Add a static-analysis pass that blocks dangerous imports such as os, subprocess, and socket before any generated code executes.
- B Have the model review its own code for destructive or exfiltrating operations and refuse to submit anything that looks unsafe.
- C Run code in an isolated sandbox with no secrets and no default egress, feeding data via host-staged files or a scoped read tool.
- D Swap the credentials for a read-only database user but keep network egress open so the code can still install needed libraries.
Answer: C. Run code in an isolated sandbox with no secrets and no default egress, feeding data via host-staged files or a scoped read tool.
A **sandbox** limits blast radius by removing anything generated code could misuse. The cost is friction: data must be staged or brokered through a narrow tool, and packages must be pre-installed. A read-only user stops destructive writes but leaves exfiltration open through egress, so it is enough only when the data is non-sensitive and outbound traffic is already blocked. Import blocklists and self-review are bypassable heuristics, not isolation.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You are defining a 'schedule_meeting' tool for an agent. Which schema decision most reduces wrong or malformed calls?
- A model emits three parallel tool calls: `get_inventory`, `get_price`, and `get_shipping`. To cut latency, the host appends each result to the transcript as it arrives and immediately re-invokes the model. Runs start failing with malformed-request errors, and some produce hallucinated shipping costs. What should the host do?
- A team splits a coding agent into planner, coder, tester, and reviewer agents, and each receives the full transcript of the previous agent. The expected quality gains did not appear. Cost tripled, and the reviewer often fixates on approaches that earlier agents abandoned. When is a multi-agent split actually justified?
- A support agent should remember each customer's preferences across months of sessions. The team appends every past session summary to the system prompt. After six months, prompts exceed 80,000 tokens, latency has doubled, and the agent sometimes ships to an address the customer replaced weeks ago. What redesign fixes both problems?
- A teammate proposes splitting a single coding agent into five agents, arguing that more agents means smarter results. When is a multi-agent split actually justified?
- A data-analysis agent runs model-generated Python inside the same container as your API service. That container has database admin credentials in environment variables. A security review flags this as critical. What is the best mitigation?