An open-data portal LLM wraps a vendor API. What should the attack-surface inventory include as LLM internals?
Select an answer to reveal the explanation.
Short Explanation
Inventory the bot’s “job description”: system prompts, tool schemas, and configs that tell it what it may do. Knowing those knobs is how you map the AI surface—not just checking the TLS sticker.
Full Explanation
Attack-surface inventory for an open-data portal LLM that wraps a vendor API must include LLM internals that steer behavior: system and user prompt patterns, tool or function schemas, retrieval configs, and related deployment settings. Civic teams with authorized access should document those control planes so testers and defenders share an accurate model of capabilities and constraints. Network certificates alone do not describe what the assistant can say or call.
Inventorying only the public website TLS certificate expiration date covers transport hygiene, not prompt/tool configuration. Focusing only on the physical rack location of the vendor’s GPU servers is irrelevant to application AI surface for a wrapped API. Limiting inventory to the city’s social-media brand guidelines addresses communications policy, not technical AI internals.
Exam caveat: LLM internals (prompts, tools, configs) are first-class inventory—TLS expiry, GPU racks, and brand guides are not substitutes. Operational check: under authorized access, export or document system prompts, tool schemas, and key configs for the open-data assistant; store them in the attack-surface register; update when vendors change defaults.