A county assessor agent framework deserializes tool results as code-executable objects. What should security require instead?
Select an answer to reveal the explanation.
Short Explanation
Tool results are data, not software you should run. Parse them safely instead of deserializing into executable objects. That “helpful” object from a tool can be a payload with legs.
Full Explanation
A county assessor agent framework that deserializes tool results as code-executable objects turns untrusted integration output into an execution path. Security should require treating tool outputs as untrusted data with safe parsing, not code execution. In civic property-valuation workflows, third-party or compromised plugins can return crafted payloads; safe parsers extract fields without instantiating executable objects, closing classic deserialization and remote-code avenues in the agent runtime.
Auto-executing any object returned by third-party assessor plugins fails by concept: it deliberately runs attacker-influenced code in the assessor agent process. Pickling untrusted tool payloads into the agent’s system prompt embeds potentially malicious serialized content into durable model context and may later be decoded unsafely. Disabling input validation to speed property-valuation callbacks removes checks that would reject malformed or unexpected tool result structures.
Exam caveat: safe parsing means schema validation and non-executing decoders (e.g., JSON to plain data structures); “eval,” unsafe pickle/YAML loaders, and native object reconstitution from tool bytes remain high risk even inside a municipal VPC. Operational check: feed the assessor agent a maliciously crafted tool result in staging, confirm it is rejected or sanitized as data, verify no code paths call deserialize-to-object or auto-exec hooks, and keep input validation enabled under load tests.