A public-benefits agent stores long-term memory of income documents in a shared vector memory store. What should security prioritize?
Select an answer to reveal the explanation.
Short Explanation
Income docs in a shared vector memory are PII with a search box. Lock down who can read it, encrypt it, and set retention — do not treat memory like a public bulletin board. Shared sticky memory of benefits files is a breach waiting for a curious query.
Full Explanation
A public-benefits agent that stores long-term memory of income documents in a shared vector memory store creates a searchable reservoir of sensitive resident financial PII. Security should prioritize access controls, encryption, and retention limits for sensitive agent memory so only authorized civic roles can retrieve embeddings or source chunks, data is protected at rest, and memory does not outlive program need. Benefits workflows often handle income verification artifacts that demand the same rigor as case-management systems.
Making the vector memory world-readable for cross-city research agents fails by concept: it maximizes unauthorized read access to income-related embeddings and chunks. Disabling audit trails on memory reads to protect resident privacy from logs confuses privacy with accountability—audit of access is a protection control, not the disclosure itself. Copying income embeddings into every agent’s system prompt nightly spreads sensitive memory into prompts, logs, and model provider surfaces.
Exam caveat: encrypting and ACL-locking vector memory protects the store; embeddings can still leak semantic information to authorized-but-curious users, so purpose limitation and query auditing still apply. Operational check: verify the benefits memory index is encrypted at rest, inaccessible to non-benefits agent roles, has a documented retention/purge job for income documents, and that memory-read audit events fire during a supervised retrieval test.