A permitting microservice conflates retrieval, generation, and payment APIs under one process identity. What separation should architecture apply?
Select an answer to reveal the explanation.
Short Explanation
When search, chat, and take-a-fee share one badge, a prompt-injection mess can reach the cash drawer. Split retrieval, generation, and payment identities so blast radius shrinks. Convenience bundling is expensive when something breaks.
Full Explanation
Conflating retrieval, generation, and payment capabilities under a single permitting microservice identity expands privileges available if a GenAI component is compromised or manipulated by prompt injection. Architecture should separate those concerns into distinct services or identities so blast radius shrinks—retrieval can search, generation can draft, and payments can charge only under their own narrowly scoped credentials and network policies. Separation of duty at the identity layer is a core GenAI application-architecture control wherever civic payments sit near language models.
Collapsing more payment functions into the LLM process for convenience maximizes coupling and privilege concentration. Running retrieval, generation, and payments as one identity with wildcards intentionally widens access contrary to least privilege. Disabling network policies so all GenAI concerns share one flat network removes segmentation that limits lateral movement after tool abuse.
Exam caveat: process colocation for latency is not a reason to share payment identity with an LLM runtime in permitting workflows. Operational check: split permitting GenAI identities by concern, apply network policies between retrieval, generation, and payment tiers, deny the LLM identity from payment APIs except via mediated workflows, and test that tool abuse cannot initiate charges.